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CHAPTER  1 


INTRODUCTION 


The  Ada  implementation  described  above  was  tested  according  to  the 
Ada  Validation  Procedures  [Pro90]  against  the  Ada  Standard  [Ada33] 
using  the  current  Ada  Compiler  Validation  Capability  (ACVC) .  This 
Validation  Summary  Report  (VSR)  gives  an  account  of  the  testing  of 
this  Ada  implementation.  For  any  technical  terms  used  in  this 
report,  the  reader  is  referred  to  [Pro90] .  A  detailed  description 
of  the  ACVC  may  be  found  in  the  current  ACVC  User's  Guide  [UG39]. 


1.1  USE  OF  THIS  VALIDATION  SUMMARY  REPORT 

Consistent  with  the  national  laws  of  the  originating  country,  the 
Ada  Certification  Body  may  make  full  and  free  public  disclosure  of 
this  report.  Jn  the  United  States,  this  is  provided  in  accordance 
with  the  "Freedom  of  Information  Act"  (5  U.S.C.  #b52).  The  results 
of  this  validation  apply  only  to  the  computers,  operating  systems, 
and  compiler  versions  identified  in  this  report. 

The  organizations  represented  on  the  signature  page  of  this  report 
do  not  represent  or  warrant  that  all  statements  set  forth  in  this 
report  are  accurate  and  complete,  or  that  the  subject 
implementation  has  no  nonconformities  to  the  Ada  Standard  other 
than  those  presented.  Copies  of  this  report  are  available  to  the 
public  from  the  AVF  which  performed  this  validation  or  from: 

National  Technical  Information  Service 
5285  Fort  Royal  Road 
Springfield  VA  22161 

Questions  regarding  this  report  or  the  validation  test  results 
should  be  directed  to  the  AVF  which  performed  this  validation  or 
to : 


Ada  Validation  Organization 

Computer  and  Software  Engineering  Division 

Institute  for  Defense  Analyses 

1801  North  Beauregard  Street 

Alexandria  VA  22311-1772 


1 . 2  REFERENCES 

[Ada33]  Reference  Manual  for  the  Ada  Programming  Language. 

ANSI/MIL-STD-1315A,  February  1983  and  ISO  8652-1987. 
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[Pro90]  Ada  Compiler  Validation  Procedures.  Version  2.1,  Ada  Joint 
Program  Office,  August  1990. 


[UG89]  Ada  Compiler  Validation  Capability  User's  Guide.  21  June 
1989  .  ' 


1.3  ACVC  TEST  CLASSES 

Compliance  of  Ada  implementations  is  tested  by  means  of  the  ACVC. 
The  ACVC  contains  a  collection  of  test  programs  structured  into  six 
test  classes:  A,  B,  C,  D,  E,  and  L.  The  first  letter  of  a  test 
name  identifies  the  class  to  which  it  belongs.  Class  A,  C,  D,  and 
E  tests  are  executable.  Class  B  and  class  L  tests  are  expected  to 
produce  errors  at  compile  time  and  link  time,  respectively. 

The  executable  tests  are  written  in  a  self-checking  manner  and 
produce  a  PASSED,  FAILED,  or  NOT  APPLICABLE  message  indicating  the 
result  when  they  are  executed.  Three  Ada  library  units,  the 
packages  REPORT  and  SPPRT13 ,  and  the  procedure  CHECK_FILE  are  used 
for  this  purpose.  The  package  REPORT  also  provides  a  set  of 
identity  functions  used  to  defeat  some  compiler  optimizations 
allowed  by  the  Ada  Standard  that  would  circumvent  a  test  objective. 
The  package  SPPRT13  is  used  by  many  tests  for  Chapter  13  of  the  Ada 
Standard.  The  procedure  CHECK_FILE  is  used  to  check  the  contents 
of  text  files  written  by  some  of  the  Class  C  tests  for  Chapter  14 
of  the  Ada  Standard.  The  operation  of  REPORT  and  CHECK_FILE  is 
checked  by  a  set  of  executable  tests.  If  these  units  are  not 
operating  correctly,  validation  testing  is  discontinued. 

Class  B  tests  check  that  a  compiler  detects  illegal  language  usage. 
Class  B  tests  are  not  executable.  Each  test  in  this  class  is 
compiled  and  the  resulting  compilation  listing  is  examined  to 
verify  that  all  violations  of  the  Ada  Standard  are  detected.  Some 
of  the  class  B  tests  contain  legal  Ada  code  which  must  not  be 
flagged  illegal  by  the  compiler.  This  behavior  is  also  verified. 

Class  L  tests  check  that  an  Ada  implementation  correctly  detects 
violation  of  the  Ada  Standard  involving  multiple,  separately 
compiled  units.  Errors  are  expected  at  link  time,  and  execution  is 
attempted. 

In  some  tests  of  the  ACVC,  certain  macro  strings  have  to  be 
replaced  by  implementation-specific  values  —  for  example,  the 
largest  integer.  A  list  of  the  values  used  for  this  implementation 
is  provided  in  Appendix  A.  In  addition  to  these  anticipated  test 
modifications,  additional  changes  may  be  required  to  remove 
unforeseen  conflicts  between  the  tests  and  implementation-dependent 
characteristics.  The  modifications  required  for  this 
implementation  are  described  in  section  2.3. 
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For  each  Ada  implementation,  a  customized  test  suite  is  produced  by 
the  AVF.  This  customization  consists  of  making  the  m.odif icat ions 
described  in  the  preceding  paragraph,  removing  withdrawn  tests  (see 
section  2.1)  and,  possibly  some  inapplicable  tests  (see  Section  3.2 
and  [UG89]). 

In  order  Lo  pass  an  ACVC  an  Ada  implementation  must  process  each 
test  of  the  customized  test  suite  according  to  the  Ada  Standard. 


1.4  DEFINITION  OF  TERMS 


Ada  Compiler  The  software  and  any  needed  hardware  that  have  to 

be  added  to  a  given  host  and  target  computer 
system  to  allow  transformation  of  Ada  programs 
into  executable  form  and  execution  thereof. 


Ada  Compiler 
Validation 
Capability 
(ACVC) 


The  means  for  testing  compliance  of  Ada 
implementations.  Validation  consisting  of  the 
test  suite,  the  support  programs,  the  ACVC 
Capability  user's  guide  and  the  template  for 
the  validation  summary  (ACVC)  report. 


Ada  An  Ada  compiler  with  its  host  computer  system  and 

I.mplementation  its  target  computer  system. 


Ada  Joint  The  part  of  the  certification  body  which  provides 

Program  policy  and  guidance  for  the  Ada  certification  Office 

(AJPO)  system. 

Ada  The  part  of  the  certification  body  which  carries 

Validation  out  the  procedures  required  to  establish  the 

Facility  (AVF)  compliance  of  an  Ada  implementation. 

Ada  The  part  of  the  certification  body  that  provides 

Validation  technical  guidance  for  operations  of  the  Ada 

Organization  certification  system. 

(AVO) 

Compliance  of  The  ability  of  the  implementation  to  pass  an  ACVC 
an  Ada  version. 

Implementation 

Com.puter  A  functional  unit,  consisting  of  one  or  more 

System  computers  and  associated  software,  that  uses 

common  storage  for  all  or  part  of  a  program  and 
also  for  all  or  part  of  the  data  necessary  for 
the  execution  of  the  program;  executes 
user-written  or  user-designated  programs;  performs 
user-designated  data  manipulation,  including 
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Conformity 


Customer 


Declaration  of 
Conformance 


Host  Computer 
System 

Inapplicable 

test 


ISO 

LRM 


Operating 

System 


Target 

Computer 

System 

Validated  Ada 
Compiler 

Validated  Ada 
Implementation 


arithmetic  operations  and  logic  operations;  and 
that  can  execute  programs  that  modify  themselves 
during  execution.  A  computer  system  may  be  a 
stand-alone  unit  or  may  consist  of  several 
inter-connected  units. 

Fulfillment  by  a  product,  process  or  service  of 
all  requirements  specified. 

An  individual  or  corporate  entity  who  enters  into 
an  agreement  with  an  AVF  which  specifies  the  terms 
and  conditions  for  AVF  services  (of  any  kind)  to 
be  performed. 

A  formal  statement  from  a  customer  assuring  that 
conformity  is  realized  or  attainable  on  the  Ada 
implementation  for  which  validation  status  is 
realized. 

A  computer  system  where  Ada  source  programs  are 
transformed  into  executable  form. 

A  test  that  contains  one  or  more  test  objectives 
found  to  be  irrelevant  for  the  given  Ada 
implementation . 

International  Organization  for  Standardization. 

The  Ada  standard,  or  Language  Reference  Manual, 
published  as  rtNi>I/HIL-STD-1815A-1983  and  ISO 
8652-1987.  Citations  from  the  LRM  take  the  form 
"<section> . <subsection> ; <paragraph> . " 

Software  that  controls  the  execution  of  programs 
and  that  provides  services  such  as  resource 
allocation,  scheduling,  inpuu/ ouupuL  control, 
and  data  management.  Usually,  operating  systems 
are  predominantly  software,  but  partial  or 
complete  hardware  implementations  are  possible. 

A  computer  system  where  the  executable  form  of  Ada 
programs  are  executed. 


The  compiler  of  a  validated  Ada  implementation. 


An  Ada  implementation  that  has  been  validated 
successfully  either  by  AVF  testing  or  by 
registration  [Pro90]. 
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Validation 


Withdrawn 

test 


The  process  of  checking  the  conformity  of  an  Ada 
compiler  to  the  Ada  programming  language  and  of 
issuing  a  certificate  for  this  implementation. 

A  test  found  to  be  incorrect  and  not  used  in 
conformity  testing.  A  test  may  be  incorrect 
because  it  has  an  invalid  test  objective,  fails 
to  meet  its  test  objective,  or  contains  erroneous 
or  illegal  use  of  the  Ada  programming  language. 
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CHAPTER  2 


IMPLEMENTATION  DEPENDENCIES 


2 . 1  WITHDRAWN  TESTS 

Some  tests  are  withdrawn  by  the  AVO  from  the  ACVC  because  they  do 
not  conform  to  the  Ada  Standard.  The  following  94  tests  had  been 
withdrawn  by  the  Ada  Validation  Organization  (AVO)  at  the  time  of 
validation  testing.  The  rationale  for  withdrawing  each  test  is 
available  from  either  the  AVO  or  the  AVF.  The  publication  date  for 
this  list  of  withdrawn  tests  is  91-05-03. 


E28005C 

B28006C 

C34006D 

C35508I 

C35508J 

C25508M 

C35508N 

C35702A 

C35702B 

B41308B 

C43004A 

C45114A 

C45346A 

C45612A 

C45612B 

C45612C 

C45651A 

C46022A 

B49008A 

B49008B 

A74006A 

C74308A 

B83022B 

B83022H 

B83025B 

B83025D 

B83026B 

C83026A 

C83041A 

B85001L 

C86001F 

C94021A 

C97116A 

C98003B 

BA2011A 

CB7001A 

CB7001B 

CB7004A 

CC1223A 

BC1226A 

CC1226B 

BC3009B 

BD1B02B 

BD1B06A 

AD1B08A 

BD2A02A 

CD2A21E  . 

CD2A23E 

CD2A32A 

CD2A41A 

CD2A41E 

CD2A87A 

CD2B15C 

BD3006A 

BD4008A 

CD4022A 

CD4022D 

CD4024B 

CD4024C 

CD4  02.4D 

CD4031A 

CD4051D 

CD5111A 

CD7004C 

ED7005D 

CD7005E 

AD7006A 

CD7006E 

AD7201A 

AD7201E 

CD7204B 

AD7206A 

BD8002A 

BD8004C 

CD9005A 

CD9005B 

CDA201E 

CE2107I 

CE2117A 

CE2117B 

CE2119B 

CE2205B 

CE2405A 

CE3111C 

CE3116A 

CE3118A 

CE3411B 

CE3412B 

CE3607B 

CE3607C 

CE3607D 

CE3812A 

CE3814A 

CE3902B 

2.2  INAPPLICABLE  TESTS 

A  test  is  inapplicable  if  it  contains  test  objectives  which  are 
irrelevant  for  a  given  Ada  implementation.  The  inapplicability 
criteria  for  some  tests  are  explained  in  documents  issued  by  ISO 
and  the  AJPO  known  as  Ada  Commentaries  and  commonly  referenced  in 
the  format  Al-ddddd.  For  this  implementation,  the  following  tests 
were  determined  to  be  inapplicable  for  the  reasons  indicated; 

references  to  Ada  Commentaries  are  included  as  appropriate. 

The  following  235  tests  have  floating-point  type  declarations 
requiring  more  digits  than  SYSTEM. MAX_DIGITS : 

C24113F..Y  (20  tests)  C35705F..Y  (20  tests) 

C35706F..Y  (20  tests)  C35707F..Y  (20  tests) 

C35708F..Y  (20  tests)  C35302F..Z  (21  tests) 
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C45241F..Y  (20  tests)  C45321F..Y  (20  tests) 
C45421F..Y  (20  tests)  C45521F..Z  (21  tests; 
C45524F..Z  (21  tests)  C45621F..Z  (21  tests) 
C45641F..Y  (20  tests)  C46012F..Z  (21  tests) 


The  following  21  tests  check  for  the  predefined  type  SHORT^IhTEGER ; 
for  this  imple’Tientation ,  there  is  no  such  type: 

C35404B  B36105C  C45231B  C45304B  C45411B 
C45412B  C45502B  C45503B  C45504B  C45504E 
C45611B  C45613B  C45614B  C45631B  C455323 
B52004E  C55B07B  B55B09D  B86001V  C36006D 
CD7101E 

C35404D,  C45231D,  B86001X,  C36006E,  and  CD7101G  check  for  a 
predefined  integer  type  with  a  name  other  than  INTEGER, 
LONG_INTEGER,  or  SHORT_INTEGER ;  for  this  implementation,  there  is 
no  such  type. 

C35713B,  C45423B,  B86001T,  and  C86006H  check  for  the  predefined 
type  SH0RT_FL0AT;  for  this  implementation,  there  is  no  such  type. 

C35713D  and  386001Z  check  for  a  predefined  floating-point  type  with 
a  name  other  than  FLOAT,  LONG_FLOAT,  or  SHORT_FLOAT;  for  this 
implementation,  there  is  no  such  type. 

C45531M..P  and  C45532M..P  (8  tests)  check  fixed-point  operations 
for  types  that  require  a  SYSTEM. MAX_MANTISSA  of  47  or  greater;  for 
this  implementation,  MAX_MANTISSA  is  less  than  47. 

C45624A..B  (2  tests)  check  that  the  proper  exception  is  raised  if 
MACHINE_OVERFLOWS  is  FALSE  for  floating  point  types  and  the  results 
of  various  floating-point  operations  lie  outside  the  range  of  the 
base  type;  for  this  implementation,  MACHINE_OVERFLOWS  is  TRUE. 

D64005G  uses  17  levels  of  recursive  procedure  calls  nesting;  this 
test  exceeds  the  linkable  size  of  64KBytes. 

ES6001Y  uses  the  name  of  a  predefined  fixed-point  type  other  than 
type  DURATION;  for  this  implementation,  there  is  no  such  type. 

C96005B  uses  values  of  type  DURATION'S  base  type  that  are  outside 
the  range  of  type  DURATION;  for  this  implementation,  the  ranges  are 
the  same. 

CA2009C  and  CA2009F  check  whether  a  generic  unit  can  be 
instantiated  before  its  body  (and  any  of  its  subunits)  is  compiled; 
this  implementation  requires  that  generic  bodies  be  located  in  the 
same  file  or  precede  the  instantiation. 


CD1009C  checks  whether  a  length  clause  can  specify  a  non-default 
size  for  a  floating-point  type;  this  implementation  does  not 
support  such  sizes. 

CD2A84A,  CD2A84E,  CD2A84I..J  (2  Lests) ,  and  CD2A840  use  length 
clauses  to  specify  non-default  sizes  for  access  types;  this 
implementation  does  not  support  such  sizes. 

B^8001A,  BD8003A,  BD8004A..B  (2  tests),  and  AD8011A  use  machine 
code  insertions;  this  implementation  provides  no  package 
MACHINE  CODE. 


CE2103A,  CE2103B,  and  CE3107A  use  an  illegal  file  name  in  an 
attempt  to  create  a  file  and  expect  NAME_ERROR  to  be  raised;  this 
implementation  does  not  support  external  files  and  so  raises 
USE_ERROR.  (See  section  2.3.) 

The  following  264  tests  check  operations  on  sequential,  text,  and 
direct  access  files;  this  implementation  does  not  support  external 
files : 


CE2102A. 

.C 

(3) 

CE2102G. 

.H 

(2) 

CE2103C. 

.  D 

(2) 

CE2104A. 

.D 

(4) 

CE2107A. 

.H 

(8) 

CE2107L 

CE2110A. 

.D 

(4) 

CE2111A. 

.1 

(9) 

CE2201A. 

.C 

(3) 

EE2201D. 

•  E 

(2) 

CE2204A. 

.D 

(4) 

CE2205A 

CE2401A. 

.C 

(3) 

EE2401D 

CE2401H. 

.L 

(5) 

CE2403A 

CE2406A 

CE2407A. 

.B 

(2) 

CE2410A. 

.  B 

(2) 

CE2411A 

CE3102J. 

.K 

(2) 

CE3103A 

CE3107B 

CE3108A. 

.B 

(2) 

CE3111A. 

.  B 

(2) 

CE3111D. 

•  E 

(2) 

CE3115A 

CE3119A 

CE3207A 

CE3208A 

CE3302A 

CE3304A 

CE3402A 

EE3402B 

CE3403E. 

•  F 

(2) 

CE3404B. 

.D 

(3) 

CE3405C. 

.  D 

(2) 

CE3406A. 

.D 

(4) 

CE3409A 

CE3409C. 

.E 

(3) 

CE3410C. 

.E 

(3) 

EE3410F 

CE3412A 

EE3412C 

CE3602A. 

.  D 

(4) 

CE3603A 

CE3606A. 

.  B 

(2) 

CE3704A. 

.F 

(6) 

CE3706D 

CE3706F. 

•  G 

(2) 

CE3806A. 

.B 

(2) 

CE3806D. 

.E 

(2) 

CE3905A. 

.  C 

(3) 

CE3905L 

CE2102K 

CE2102N. . Y 

(12) 

CE2105A. 

.  B 

(2) 

CE2106A. . B 

(2) 

CE2108A. 

.H 

(8) 

CE2109A. .C 

(3) 

CE2115A. 

.B 

(2) 

CE2120A. .B 

(2) 

CE2201F. 

.N 

(9) 

CE2203A 

CE2206A 

CE2208B 

CE2401E. 

.F 

(2) 

EE2401G 

CE2404A. 

.  B 

(2) 

CE2405B 

CE2408A. 

.  B 

(2) 

CE2409A. . B 

(2) 

CE3102A. 

.  C 

(3) 

CE3102F. .H 

(3) 

CE3104A. 

.C 

(3) 

CE3106A. .B 

(2) 

CE3109A 

CE3110A 

CE3112A. 

.D 

(4) 

CE3114A. . B 

(2) 

EE3203A 

EE3204A 

CE3301A 

EE3301B 

CE3305A 

CE3401A 

CE3402C. 

.D 

(2) 

CE3403A. .C 

(3) 

CE3405A 

EE3405B 

CE3407A. 

•  C 

(3) 

CE3408A. .C 

(3) 

EE3409F 

CE3410A 

CE3411A 

CE3411C 

CE3413A. 

.C 

(3) 

CE3414A 

CE3604A. 

.B 

(2) 

CE3605A. .E 

(5) 

CE3704M. 

.0 

(3) 

CE3705A. .E 

(5) 

CE3804A. 

.  P 

(16) 

CE3805A. .B 

(2) 

CE3806G. 

.H 

(2) 

CE3904A. .B 

(2) 

CE3906A. 

.C 

(3) 

CE3906E. . F 

(2) 
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2.3  TEST  MODIFICATIONS 


Modifications  (see  section  1  3)  were  required  for  13  tests. 

The  following  tests  were  split  into  two  or  more  tests  because  this 
implementation  did  not  report  the  violations  of  the  Ada  Standard  in 
the  way  expected  by  the  original  tests. 

B33301B  B55A01A  B83E01C  B83E01D  B83E01E  BAIOOIA  BAllOlB  BC1109A 
BC1109C  BC1109D 


C83030C  and  C86007A  were  graded  passed  by  Test  Modification  as 
directed  by  the  AVO.  These  tests  were  modified  by  inserting 
"PRAGMA  ELABORATE  (REPORT);"  before  the  package  declarations  at 
lines  13  and  11,  respectively.  Without  the  pragma,  the  packages 
may  be  elaborated  prior  to  package  Report's  body,  and  thus  the 
packages'  calls  to  function  REPORT. IDENT_INT  at  lines  14  and  13, 
respectively,  will  raise  PROGRAM_ERROR . 

BC3204C  and  BC3205D  were  graded  passed  by  Processing  Modification 
as  directed  by  the  AVO.  These  tests  check  that  instantiations  of 
generic  units  with  unconstrained  types  as  generic  actual  parameters 
are  illegal  if  the  generic  bodies  contain  uses  of  the  types  that 
require  a  constraint.  However,  the  generic  bodies  are  compiled 
after  the  units  that  contain  the  instantiations,  and  this 
implementation  creates  a  dependence  of  the  instantiating  units  on 
the  generic  units  as  allowed  by  AI-00408  and  AI-00506  such  that  the 
compilation  of  the  generic  bodies  makes  the  instantiating  units 
obsolete — no  errors  are  detected.  The  processing  of  these  testi 
was  modified  by  re-compiling  the  obsolete  units;  all  intendec 
errors  were  then  detected  by  the  compiler. 

CE2103A,  CE2103B,  and  CE3107A  were  graded  inapplicable  by 
Evaluation  Modification  as  directed  by  the  AVO.  The  tests  abort 
with  an  unhandled  exception  when  USE_ERROR  is  raised  on  the  attempt 
to  create  an  external  file.  This  is  acceptable  behavior  because 
this  implementation  does  not  support  external  files  (cf .  AI-00332) . 

EE3412C  was  graded  passed  by  Test  Modification  as  directed  by  the 
AVO.  This  test  assumes  that  the  support  package  REPORT  uses 
TEXT_IO,  and  that  thus  calls  to  REPORT. SPECIAL_ACTION  will 
increment  the  line  count  on  the  standard  output  file.  But  REPORT 
was  modified  to  use  the  implementation-defined  string  I/O  package 
named  STRING_OUTPUT  instead  of  TEXT_IO,  because  TEXT_IO  is  large  in 
terms  of  object  code  size.  STRING_OUTPUT  is  significantly  smaller 
than  TEXT_IO,  and  provides  for  the  output  needs  of  REPORT  while 
allowing  for  the  executable  images  of  the  tests  to  fit  within  a 
64KByte  memory  limit.  Because  STRING_IO  operations  do  not  affect 
the  status  of  TEXT_IO  files — i.p.,  the  line  count  for  standard 
output  file  is  unchanged — ,  line  46  of  the  test  was  chaned  as 
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follows : 


from:  IF  LINE  /=  C+2  THEN 
to:  IF  LINE  /=  C+1  THEN 

Although  REPORT  is  not  a  test,  the  modifications  to  it  is  recorded 
here  to  complete  the  record  and  to  allow  for  accurate  replication 
of  this  test  environment.  REPORT  body  was  modified  to  use  a 
package  named  STRING_OUTPUT  rather  than  TEXT_IO  because  TEXT_IO  is 
large  in  terms  of  compiled  object  code  size.  STRING_OUTPUT  is 
significantly  smaller  than  TEXT_IO  and  provides  for  the  output 
needs  of  REPORT  while  allowing  for  the  executable  image  of  the 
tests  to  fit  within  a  64KByte  memory  limit. 
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CHAPTER  3 


PROCESSING  INFORMATION 


3 . 1  TESTING  ENVIRONMENT 

The  Ada  implementation  tested  in  this  validation  effort  is 
described  adequately  by  the  information  given  in  the  initial  pages 
of  this  report. 

The  tests  were  compiled  and  linked  on  the  host  computer  system,  as 
appropriate.  The  executable  images  were  transferred  to  the  target 
computer  system  by  the  communications  link  described  above,  and 
run.  The  results  were  captured  on  the  host  computer  system. 

For  technical  information  about  this  Ada  implementation,  contact: 

Ms.  Gail  Ward 
InterACT  Corporation 
417  5th  Avenue 

New  York,  New  York,  U.S.A.  10016 

For  sales  information  about  this  Ada  implementation,  contact: 

Mr.  Rich  Colucci 
InterACT  Corporation 
417  5th  Avenue 

New  York,  New  York,  U.S.A.  10016 

Testing  of  this  Ada  implementation  was  conducted  at  the  customer's 
site  by  a  validation  team  from  the  AVF. 

3.2  SUMMARY  OF  TEST  RESULTS 

An  Ada  Implementation  passes  a  given  ACVC  version  if  it  processes 
each  test  of  the  customized  test  suite  in  accordance  with  the  Ada 
Programming  Language  Standard,  whether  the  test  is  applicable  or 
inapplicable;  otherwise,  the  Ada  Implementation  fails  the  ACVC 
[Pro90] . 

For  all  processed  tests  (inapplicable  and  applicable) ,  a  result  was 
obtained  that  conforms  to  the  Ada  Programming  Language  Standard. 

The  list  of  items  below  gives  the  number  of  ACVC  tests  in  various 
categories.  All  tests  were  processed,  except  those  that  were 
withdrawn  because  of  test  errors  (item  b;  see  section  2.1),  those 
that  require  a  floating-point  precision  that  exceeds  the 
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implementation's  maximum  precision  (item  e;  see  section  2.2),  and 
those  that  depend  on  the  support  of  a  file  system  —  if  none  is 
supported  (item  d)  .  All  tests  passed,  except  those  that  are  listed 
in  sections  2.1  and  2.2  (counted  in  items  b  and  f,  below). 


a)  Total  Number  of  Applicable  Tests  3466 

b)  Total  Number  Oi.  Withdrawn  Tests  94 

c)  Processed  Inapplicable  Tests  610 

d)  Non-Processed  I/O  Tests  0 

e)  Non-Processed  Floating-Point 

Precision  Tests  0 


f)  Total  Number  of  Inapplicable  Tests  610  (c+d+e) 

g)  Total  Number  of  Tests  for  ACVC  1.11  4170  (a+b+f) 


3 . 3  TEST  EXECUTION 

A  magnetic  tape  containing  the  customized  test  suite  (see  section 
1.3)  was  taken  on-site  by  the  validation  team  for  processing.  The 
contents  of  the  magnetic  tape  were  loaded  directly  onto  the  host 
computer. 

The  Ada  source  files  are  compiled  on  a  MicroVAX  3100  Cluster  under 
VAX/VMS  using  the  InterACT  Ada  1750A  Compiler  System.  The  Ada  main 
programs  are  then  linked  on  the  MicroVAX  Cluster  using  InterACT 
1750A  Linker  which  produces  a  load  module  in  InterACT 's  own  load 
format. 

This  load  format  is  loaded  and  then  executed  within  the  InterACT 
MIL-STD-1750A  Instruction  Set  Architecture  Simulator  which  also 
executes  on  the  MicroVAX  3100  Cluster.  The  Symbolic  Debugging  and 
Simulation  System  runs  a  set  script  consisting  only  of  "load", 
"go",  and  "exit"  commands.  The  MIL-STD-1750A  Instruction  Set 
Architecture  Simulator  is  a  complete  instruction  set  simulator  for 
the  MIL-STD-1750A  architecture.  The  1750A  Console  Output 
instruction  in  the  MIL-STD-1750A  Instruction  Set  Architecture 
Simulator  is  defined  to  write  character  output  (representing  the 
Ada  standard  output)  to  a  dedicated  Ada  output  file.  The  dedicated 
Ada  output  file  contains  the  output  from  the  ACVC  tests. 

After  the  test  files  were  loaded  onto  the  host  computer,  the  full 
set  of  tests  was  processed  by  the  Ada  implementation. 

The  tests  were  compiled  and  linked  on  the  host  computer  system,  as 
appropriate.  The  InterACT  MIL-STD-1750A  Instruction  Set 
Architecture  Simulator,  Release  2.3  (Bare  Machine)  [target  computer 
system]  runs  on  the  host  computer  system.  The  executable  images 
were  transferred  to  the  target  computer  system  by  the 
communications  link  described  above,  and  run.  The  results  were 
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captured  on  the  host  computer  system. 

Testing  was  performed  using  command  scripts  provided  by  the 
customer  and  reviewed  by  the  validation  team.  See  Appendix  B  for 
a  complere  listing  of  the  processing  options  for  this 
implementation.  It  also  indicates  the  default  options.  The 
options  invoked  explicitly  for  validation  testing  during  this  test 
were: 

For  all  tests  the  following  explicit  option  was  invoked: 

/ 1 ibrary=< 1 ibrary_name> 

In  addition  to  the  above,  the  following  explicit  option  was  invoked 
for  the  B  tests  and  E  tests: 

/list 

Test  output,  compiler  and  linker  listings,  and  job  logs  were 
captured  on  magnetic  tape  and  archived  at  the  AVF.  The  listings 
examined  on-site  by  the  validation  team  were  also  archived. 
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APPENDIX  A 


MACRO  PARAMETERS 


This  appendix  contains  the  macro  parameters  used  for  customizing 
the  ACVC.  The  meaning  and  purpose  of  these  parameters  are 
explained  in  [UG89].  The  parameter  values  are  presented  in  two 
tables.  The  first  table  lists  the  values  that  are  defined  in  terms 
of  the  maximum  input-line  length,  which  is  the  value  for 
$MAX_IN_LEN — also  listed  here.  These  values  are  expressed  here  as 
Ada  string  aggregates,  where  "V  represents  the  maximum  input-line 
length. 

Macro  Parameter  Macro  Value 


$MAX  IN  LEN  126  —  Value  of  V 


$BIG_ID1 

(1. .V-1  =>  'A' ,  V 

=>  '!') 

$BIG_ID2 

(1. .V-1  =>  'A' ,  V 

=>  '2') 

$BIG_ID3 

(1. .V/2  =>  'A' )  &  ' 

3  '  &  (1. .V-l-V/2  => 

'A'  ) 

$BIG_ID4 

(1. .V/2  =>  'A' )  &  ' 

4  '  &  (1. .V-l-V/2  => 

'A'  ) 

$BIG_INT_LIT 

(1. .V-3  =>  'O' )  & 

"298" 

$BIG_REAL_LIT 

(1. .V-5  =>  '0')  & 

"690.0" 

$BIG_STRING1 

""  &  (1. .V/2  => 

'  A  ’  )  &  "" 

$BIG_STRING2 

""  &  {1..V-1-V/2 

=>  'A')  &  &  "" 

$ BLANKS 

(1. .V-20  =>  '  ' ) 

$MAX_LEN_INT_BASED_LITERAL 

"2:"  &  (1.  .V-5  =>  '0')  &  "11: '• 

$MAX_LEN_REAL_BASED_LITERAL 

"16:"  &  (1..V-7  =>  '0')  &  "F.E:" 

$MAX_STRING_LITERAL  ""  &  (1..V-2  =>  'A')  &  "" 
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The  following  table  contains  the  values  for  the  remaining 
macro  parameters. 

Macro  Parameter  Macro  Value 


$ACC_SIZE 

$ALIGNMENT 

$COUNT_LAST 

$  DE  FAULT_MEM_S I Z  E 

$DEFAULT_STOR_UNIT 

$  DEF AULT_S  YS_NAME 

$DELTA_DOC 

$ENTRY_ADDRESS 

$ENTRY_ADDRESS1 

$ENTRY_ADDRESS2 

$FIELD_LAST 

$FILE_TERMINATOR 

$FIXED_NAME 

$FLOAT_NAME 

$FORM_STRING 

$FORM_STRING2 

$GREATER  THAN  DURATION 


16 

1 

2_147_483_647 

65536 

16 

MIL_STD_1750A 

1.0/2 . U** (SYSTEM. MAX_MANTISSA) 
12 

13 

14 
35 

)  t 

NO_SUCH_FIXED_TYPE 

NO_SUCH_FLOAT_TYPE 

tl  tl 

” CANNOT_RESTRI CT_FILE_CAPACITY " 
214  748.3647 


$GREATER_THAN_DURATION_BASE_LAST  214_749 . 3647 

$GREATER_THAN_FLOAT_BASE_LAST 

2#0. lllllll_llllllll_llllll#E127 

$GREATER_THAN_FLOAT_SAFE_LARGE  0.999999E128 

$GREATER_THAN_SHORT_FLOAT_SAFE_LARGE  0 . 0 

$HIGH  PRIORITY  255 
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S I LLEGAL_EXTERNAL_F I LE_NAME 1  I LLEGAL_F I LE_N AME_ 1 
$ILLEGAL_EXTERNAL_FILE_NAME2  ILLEGAL_FILE_NAME_2 
$INAPPROPRIATE_LINE_LENGTH  -1 
$ INAPPROPRIATE  PAGE  LENGTH  -1 


$ INCLUDE  PRAGMAl 


PRAGMA  INCLUDE ("A28006D1.TST") 


$ INCLUDE  PRAGMA2 


PRAGMA  INCLUDE ("B28006F1.TST") 


$ INTEGER  FIRST 


-32768 


$INTEGER  LAST 


32767 


$ INTEGER  LAST  PLUS  1 


32768 


$ INTERFACE  LANGUAGE 


ASSEMBLY 


$LESS  THAN  DURATION 


-214  748.3648 


$LESS_THAN_DURATION_BASE_FIRST  -214_749 . 3648 
$LINE_TERMINATOR  ' ' 

$LOW  PRIORITY  0 


$MACHINE  CODE  STATEMENT 


NULL; 


$MACHINE  CODE  TYPE 


NO  SUCH  TYPE 


$MANTISSA_DOC 
SMAX  DIGITS 


$MAX  INT 


2147483647 


$MAX  INT  PLUS  1 


2147483648 


$MIN  INT 


-2147483648 


$NAME 


NO  SUCH  INTEGER  TYPE 


$NAME  LIST 


MIL  STD  1750A 


$NAME  SPECIFICATION! 


NAME  SPEC  1 


$NAME  SPECIFICATION2 


NAME  SPEC  2 


$NAME  SPECIFICATIONS 


NAME  SPEC  3 
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$NEG_BASED_INT 

$NEW_MEM_SIZE 

$NEW_STOR_UNIT 

$NEW_SYS_NAME 

$PAGE_TERMINATOR 

$RECORD_DEFINITION 

$RECORD_NAME 

$TASK_SIZE 

$TAS  K_STORAGE_S I Z  E 

$TICK 

$VARIABLE_ADDRESS 
$VARIABLE_ADDRESS 1 
$VARIABLE_ADDRESS2 
$YOUR  PRAGMA 


16#FFFFFFFE# 

65536 

16 

MIL_STD_1750A 

I  t 

NEW  INTEGER; 

NO_SUCH_MACHINE_CODE_TYPE 

16 

1024 

0 . 000_100 
16#1000# 

16#1S00# 

16#2000# 

N  A 
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APPENDIX  B 


COMPILATION  SYSTEM  OPTIONS 


The  compiler  options  of  this  Ada  implementation,  as  described  in  this 
Appendix,  are  provided  by  the  customer.  Unless  specifically  noted 
otherwise,  references  in  this  appendix  are  to  compiler  documentation  and 
not  to  this  report. 
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Chapter  4 
The  Ada  Compiler 


The  Ada  Compiler  translates  Ada  source  code  into  MIL-STT)-1750A  object  code. 

Diagnostic  messages  are  produced  if  any  errors  in  the  source  code  are  deteacd.  Warning  messages  are  also 
produced  when  appropriate. 

Compile,  aoss-reference,  and  generated  assembly  code  listings  are  available  upon  user  request. 

The  compiler  uses  a  program  libran  during  the  compilation.  An  internal  representation  of  the  compilation, 
which  includes  any  dependencies  on  units  already  in  the  program  library,  is  stored  in  the  program  library  as  a 
result  of  a  successful  compilation. 

On  a  successful  compilation,  the  compiler  generates  assembly  code,  invokes  the  InterACT  I750A  Assembler  to 
transbte  this  assembly  code  into  objea  code,  and  then  stores  the  object  code  in  the  program  library.  (Option¬ 
ally,  the  generated  assembly  code  may  also  be  stored  in  the  library.)  The  invocation  of  the  Assembler  is  com¬ 
pletely  transparent  to  the  user. 


4.1.  The  Invocation  Command 

The  Ada  Compiler  is  invoked  by  submitting  the  following  VaX/VMS  command: 

$  adal750{qualifier}  source-fde-sptc 

4.1.1.  Parameters  and  Qualifiers 

Default  values  exist  for  all  qualifiers  as  indicated  below.  All  qualifier  names  may  be  abbreviated  (characlen 
omitted  brom  the  right)  as  long  as  no  ambiguity  arises. 

sourte-file-ipec 

This  parameter  spedTies  the  file  containing  the  source  text  to  be  compiled.  Any  valid  VAX/VMS  filename  may 
be  used.  If  the  fJe  type  is  omitted  from  the  spedfication,  file  type  ada  is  assumed  by  default.  If  this  parameter 
is  omitted,  the  user  will  be  prompted  for  it.  The  format  of  the  source  text  is  described  in  Section  4.2. 
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The  Ada  Compiler 


/list 

/nolist  (default) 

The  user  may  request  a  source  listing  by  means  of  the  qualifier  /list.  The  source  listing  is  written  to  the  list  file, 
Seaion  432  contains  a  description  of  the  source  listing. 

If  /nolist  is  active,  no  source  listing  is  produced,  regardless  of  any  LIST  pragmas  in  the  program  or  any  diagnos¬ 
tic  messages  produced. 

In  addition,  the  /list  qualifier  provides  generated  assembly  listings  for  each  compilation  unit  in  the  source  file. 
Section  43.6  contains  a  description  of  the  generated  assembly  listing. 

/xref 

/noxref  (default) 

A  cross-reference  listing  can  be  requested  by  the  user  by  means  of  this  qualifier.  If  /xref  is  aaive  and  no  severe 
or  fatal  errors  arc  found  during  the  compilation,  the  cross-reference  listing  is  written  to  the  list  file.  The  cross- 
reference  lining  is  described  in  Section  43.4. 

/library  =  file-spec 

/\ibnry-adal7S0  library  (default) 

This  qualifier  specifies  the  current  sublibrary  and  thereby  also  specifies  the  current  program  library  which  con¬ 
sists  of  the  current  sublibrary  through  the  root  sublibrary  (see  Chapter  2).  If  the  qualifier  is  omitted,  the  subli¬ 
brary  designated  by  the  logical  name  adal750Jihnry  is  used  as  the  current  sublibrary. 

Section  4.4  describes  how  the  Ada  compiler  uses  the  current  sublibrary. 

/configuratioo^rile  =  file-spec 

/configuratioa  tUe^adal750  config  (default) 

This  qualifier  specifies  the  configuration  file  to  be  used  by  the  compiler  in  the  current  compilation. 

If  the  qualifier  is  omitted,  the  configuration  file  designated  by  the  logical  name  adal750  config  is  used  by 
default.  Section  4.1.4  contains  a  description  of  the  configuration  file. 

/save_soun*  (default) 

/oosave  source 

This  qualifier  specifies  whether  the  source  text  of  the  compuation  unit  is  stored  in  the  program  library.  In  case 
that  the  source  text  file  contains  several  compilation  units  the  source  text  for  each  compilaaon  unit  is  stored  in 
the  program  library.  The  source  texts  stored  in  the  program  library  can  be  extraaed  using  the  Ada  PLU  type 
command  (see  Chapter  3). 

Spedfiing  /nosave_source  will  prevent  automatic  recompilation  by  the  Ada  Recompilcr.  and  is  hence  not 
recommended. 
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/keep^assembly 

/ookecp^asscmbly  (default) 

^^'hcn  this  qualifier  is  given,  the  compiler  will  store  the  generated  assembly  source  code  In  the  program  library, 
for  each  compilation  unit  being  compiled.  By  default  this  is  not  done.  Note  that  while  the  assembly  code  es 
stored  in  the  library  in  a  compressed  form,  it  nevertheless  takes  up  a  large  amount  of  library  space  relative  to 
the  other  information  stored  in  the  library  for  a  program  unit. 

This  qualifier  does  not  affect  the  production  of  generated  assembly  listings. 

/check  (default) 

/nocheckj  =  (check  kind,...)] 

check  Jdnd ::  =  Index  ]  access  |  discriminant  |  length  |  range  | 
division  {  overflow  |  elaboration  |  storage  |  all 


^Vhcn  this  qualifier  is  active  (which  is  the  default),  all  run  lime  checks  will  be  generated  by  the  compiler. 

^hen  /nocheck  is  specified,  the  checks  corresponding  to  the  particular  check  kinds  specified  will  be  omitted. 
These  kinds  correspond  to  the  identifiers  defmed  for  pragma  SUPPRESS  [Ada  RM  JJ.7].  The  default  kmd  for 
/nocheck  is  all;  that  is,  just  specifying  /nocheck  results  in  all  checks  being  suppressed. 

Suppression  of  checks  is  done  in  the  same  manner  as  for  pragma  SUPPRESS  (see  Section  F.2). 

/debug 

/nodebug  (default) 

V^fhen  this  qualifier  is  given,  the  compiler  will  generate  symbolic  debug  information  for  each  compilation  unit  a. 
the  source  file  and  store  the  information  in  the  program  library.  By  default  this  is  not  done. 

This  symbolic  debug  information  is  used  by  the  InterACT  Symbolic  Debugging  System. 


It  is  important  to  note  that  the  identical  objea  code  is  produced  by  the  compiler,  whether  or  not  the  /debog 
qualifier  is  active.  There  arc  some  minor  differences  in  the  generated  assembly  code,  due  to  some  extra  labels 
being  generated  in  the  debug  case. 

/nofeoptimizc 

A  small  fKjrtion  of  the  optimizing  capability  of  the  compiler  places  capacity  limits  on  the  source  program  (ex,  | 
number  of  variables  in  a  compilation  unit)  that  are  more  restrictive  than  those  documented  in  Section  F.13.  U  a 
compile  produces  an  error  message  indicating  that  one  of  these  limits  has  been  reached,  for  example 

1562S-0:  Optinizer  capacity  exceeded.  Too  many  names  in  a  basic  block. 


then  use  of  this  /nofeoptimize  qualifier  will  bypass  this  particular  optimizing  capability  and  allow  the  compila- 
lion  to  finish  normally. 

IMPORTAI'IT  NOTE:  Do  not  use  this  qualifier  for  any  other  reason.  Do  not  attempt  to  use  it  in  its  posieve 
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form  (/feoptioiize),  either  with  or  without  any  of  it£  keyword  parameters.  The  /feoptimize  qualifier  as  defmed 
in  the  delivered  command  defuiition  file  is  preset  to  produce  the  most  effective  optimization  possible;  any  other 
use  of  it  may  produce  either  non-opdmal  or  incorrect  generated  code.  Similarly,  do  not  use  any  other  qualifiers 
defmed  in  the  delivered  command  defuiition  file  that  are  not  documented  in  this  manual.  Such  qualifiers  are 
intended  only  for  compiler  maintenance  purposes. 

/progress 

/noprogress  (default) 

When  this  qualifier  is  given,  the  compiler  will  write  a  message  to  sysSoutpnt  as  each  pass  of  the  compiler  starts 
to  run.  This  information  is  not  provided  by  default. 


Examples  of  qualifier  usage 

$  adal750  navigatioa_constants 
$  adal750/1ist/xref  event_scheduler 

S  adal750/prog/Iib  =  test_versioas.alb  sysSuser [source] altitudes  b 


4.1  Tbe  Ust  File 

The  name  of  the  list  file  is  identical  to  the  name  of  the  source  file  except  that  it  has  the  file  type  lis.  The  file  is 
located  in  the  current  default  directory.  If  any  such  file  exists  prior  to  the  compilation,  the  newest  version  of^  the 
file  is  deleted.  If  the  user  requests  any  listings  by  specifying  the  qualifiers  /list  or  /xref,  a  new  list  file  is  created. 

The  list  file  is  a  text  file  and  its  contents  are  desenbed  in  Section  43. 


4.13.  Tbe  Diagnostic  File 

The  name  of  the  diagnostic  file  is  identical  to  the  name  of  the  source  file  except  that  it  has  the  file  type  err.  It  is 
located  in  the  current  default  directory.  If  any  such  file  exists  prior  to  the  compilation,  the  newest  version  of  the 
file  is  deleted.  If  any  diagnostic  messages  are  produced  during  the  compilation,  a  new  diagnostic  file  is  aeated. 

The  diagnostic  file  is  a  text  file  containing  a  list  of  diagnostic  messages,  each  followed  by  a  line  showing  the 
number  of  the  line  in  the  source  text  causing  the  message,  and  a  blank  line.  There  is  no  pagination  and  there 
are  no  headings.  The  file  may  be  used  by  an  interactive  editor  to  show  the  diagnostic  messages  together  with 
the  erroneous  source  text  (see  Appendix  A).  The  diagnostic  messages  are  desenbed  in  Section  433. 


4.1.4.  The  Conflguradoo  FUc 

Certain  functional  characteristics  of  the  compiler  may  be  modified  by  the  user.  These  characteristics  are  passed 
to  the  compiler  by  means  of  a  configuration  file,  which  is  a  text  file.  The  contents  of  the  configuration  file  must 
be  an  Ada  positional  aggregate,  written  on  one  line,  of  the  anonymous  type  configuration  record,  which  is 
descn’bed  below.  The  configuration  file  is  not  accepted  by  tbe  compiler  in  the  following  cases: 
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•  the  syntax  does  not  conform  with  the  syntax  for  a  positional  Ada  aggregate  of  type 
conpgfiratunjtcord; 

•  a  value  is  outside  the  ranges  spedTied  below, 

•  a  value  is  not  specified  as  a  literal; 

•  LINES_PER_PAGE  is  not  greater  than  TOP  MARGIN  +  BOTTOM  MARGIN; 

•  the  aggregate  occupies  more  than  one  line. 

If  the  compiler  is  unable  to  accept  the  configuration  file,  an  error  message  is  issued  and  the  compilation  is  ter¬ 
minated. 

The  definition  of  this  anonymous  type  is 

type  OLTFORMATTING  is 
record 

LINES_PER_PAGE  :  INTEGER  range  30..100; 

--see  Section  4J.1 

TOP_MARGIN  :  INTEGER  range  4..  90; 

-sec  Section  43.1 

BOTTOM_MARGIN  ;  INTEGER  range  0..  90; 

-see  Section  43.1 

OUT_LINEUENGTH  :  INTEGER  range  80..132; 

-see  Section  43.1 

SUPPRESS_ERRORNO  :  BOOLEAN; 

-see  Section  433.1 
end  record; 


type  INPUT  FORMATS  is 

( ASen  );” 

-see  Section  4.2 


type  ENFORMATTTNG  is 
record 

INPUT_F0RMAT  ;  INPUT  FORMATS; 

-see  Section  4.2 

INPUT_LINELENGTH  :  INTEGER  range  70..127; 
-see  Section  43 
end  record; 


type  configuntionjecord  is 
record 

IN  FORMAT :  INFORMATTING; 

OUT  FORMAT :  OUTFORMATTING; 
ERROR  UMIT ;  INTEGER; 

-sec  Section  433 
end  record; 
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The  Compiler  System  is  delivered  with  a  configuration  file  with  the  following  content: 

((ASCII,  126),  (48,  5,  3, 100,  FALSE),  200) 

The  name  of  configuration  file  is  passed  to  the  compiler  through  the  /configuiation^nie  qualifier. 

The  OUTFORMATTING  components  have  the  following  meaning: 

•  LINES  PER  PAGE  Spedfles  the  maximum  number  of  lines  written  on  each  page  (including  top  and 
bottom  margin). 

•  TOP  MARGIN:  Specifies  the  number  of  lines  on  top  of  each  page  used  for  a  standard  heading  and 
blank  line.<  The  heading  is  placed  in  the  middle  lines  of  the  top  margin. 

•  BOTTOM  MARGIN:  Spedfies  the  minimum  number  of  lines  left  blank  in  the  bottom  of  the  page. 
The  number  of  lines  available  for  the  listing  of  the  program  is  LINES  PER  PAGE  -  TOP  MARGIN 
-  BOTTOM  MARGIN. 

•  OUT  LINELENGTH:  Spedfies  the  maximum  number  of  characters  written  on  each  line.  Lines 
longer  than  OUT  LINELENGTH  are  separated  into  two  lines. 

•  SUPPRESS  ERRORNO:  Specifies  the  format  of  error  messages,  see  Section  43.5.1. 


4J  J.  The  Generated  Assembly  List  File 

When  generated  assembly  list  files  are  produced,  there  is  one  such  file  for  each  compilation  unit  m  the  source 
file.  Generated  assembly  list  files  have  a  file  type  of  als,  and  a  file  name  of  the  compilation  unit  name  suffixed 
with  a  $s  if  the  compilation  unit  is  a  specification,  or  $b  if  the  compilation  unit  is  a  body.  Ail  files  are  located  in 
the  current  default  directory.  Unlike  the  source  list  file,  existing  generated  assembly  list  files  are  not  deleted 
upon  recompilation. 

Generated  assembly  list  files  are  text  files  and  their  contents  are  described  in  Section  43.6. 


43.  The  Source  Text 

The  user  submits  one  source  text  file  in  each  compilation.  The  source  text  may  consist  of  one  or  more  compila¬ 
tion  units  [Ada  RM  10.1]. 

On  VAX/VMS  the  format  of  the  source  text  specified  in  the  configuration  file  (see  Section  4.1.4)  must  be 
ASCn.  This  format  requires  that  the  source  text  is  a  sequence  of  ISO  characters  [ISO  standard  646),  where 
each  line  is  terminated  by  one  of  the  following  termination  sequences  (CR  means  carnage  return,  VT  means 
vertical  tabulation,  LF  means  line  feed,  and  FF  means  form  feed): 

•  a  sequence  of  one  or  more  CRs,  where  the  sequence  is  neither  immediately  preceded  nor  immediately 
followed  by  any  of  the  charaaers  VT,  LF,  or  FF; 

•  any  of  the  characters  VT,  LF,  or  FF,  immediately  preceded  and  followed  by  a  sequence  of  zero  or 
more  CRs. 

In  general,  ISO  control  characters  arc  not  permitted  in  the  source  text  with  the  following  exceptions: 
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•  the  horizontal  tabuladon  character  (HT)  may  be  used  as  a  separator  between  lexical  units; 

•  LF,  VT,  FF,  and  CR  may  be  used  to  terminate  lines,  as  described  above. 

The  maximum  number  of  characters  in  an  input  line  is  determined  by  the  contents  of  the  configuration  fDe  (see 
Section  4.1.4).  The  control  characters  CR,  VT,  LF,  and  FF  are  not  considered  part  of  the  line.  Lines  containing 
more  than  the  maximum  number  of  characters  are  truncated  and  an  error  message  is  issued. 


43.  Compiler  Output 

The  compiler  may  produce  output  in  the  list  file,  the  generated  assembly  list  filefs),  the  diagnostic  file,  and  on 
sysSoutpuL  It  also  updates  the  program  library  if  the  compilation  is  successful  (see  Section  4.4). 

The  compiler  may  produce  the  following  text  output: 

1.  A  listing  of  the  source  text  with  embedded  diagnostic  messages  is  written  to  the  list  file,  if  the  qualifier 
/list  is  active. 

2.  A  compilation  summary  is  written  to  the  list  file,  if  /list  is  active. 

3.  A  aoss-reference  listing  is  written  to  the  list  file,  if  /xref  is  active  and  no  severe  or  fatal  errors  have 
been  detected  during  the  compilation. 

4.  A  generated  assembly  listing  of  the  compilation  units  within  the  source  file  is  written  to  the  generated 
assembly  Ust  rile(s)  if  the  qualifier  /list  is  active,  and  if  no  errors  have  been  deteaed  during  the  com¬ 
pilation. 

5.  If  there  are  any  diagnostic  messages,  a  diagnostic  file  containing  the  messages  is  written. 

6.  Diagnostic  messages  other  than  warnings  are  written  to  sysSoutput. 


4J.1.  Format  of  the  List  File 

The  list  file  may  include  one  or  more  of  the  following  parts:  a  source  listing,  a  cross-reference  listing,  and  a 
compilation  summary. 

The  parts  of  the  list  file  are  separated  by  page  ejects.  The  contents  of  each  part  are  described  in  the  following 
sections. 

The  format  of  the  output  to  the  list  file  is  controlled  by  the  configuration  file  (see  Section  4.1.4). 


4JJ.  Source  Listing 

A  source  listing  is  an  unmodified  copy  of  the  source  text.  The  listing  is  divided  into  pages  and  each  line  is  sup¬ 
plied  with  a  line  number. 

The  number  of  lines  output  in  the  source  listing  is  governed  by  the  following: 
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•  parts  of  the  listing  can  be  suppressed  by  the  use  of  LIST  pragmas; 

•  a  line  containing  a  construct  that  caused  a  diagnostic  message  to  be  produced  is  printed  even  if  it 
occurs  at  a  point  where  listing  has  been  suppressed  by  a  LIST  pragma. 

An  example  of  a  source  listing  is  shown  in  Chapter  10. 


4JJ.  CompUadoo  Summary 

At  the  end  of  a  compiladon  the  compiler  produces  a  summary  that  is  output  to  the  list  file  if  the  /list  qualifier 
is  active. 

The  summary  contains  informadon  about: 

•  the  type  and  name  of  the  compiladon  unit,  and  whether  it  has  been  compiled  successfully  or  not; 

•  the  number  of  diagnosdc  messages  produced,  for  each  class  of  severity  (see  Secdon  435); 

•  which  qualifiers  were  aedve; 

•  the  VAX/VMS  filename  of  the  source  file; 

•  the  VAX/VMS  filenames  of  the  sublibraries  constituting  the  current  program  library, 

•  the  number  of  source  text  lines; 

•  elapsed  real  time  and  elapsed  CPU  time; 

•  a  ‘Compiladon  terminated’  message  if  the  compiladon  unit  was  the  last  in  the  compiladon,  or  ‘Com* 
piladon  of  next  unit  initiated*  otherwise. 

An  example  of  a  compiladon  summary  is  shown  in  Chapter  10. 


43.4.  Cross-Reference  Listing 

A  cross-reference  listing  is  an  alpbabedcally  sorted  list  of  the  identifiers,  operators  and  character  literals  of  a 
compiladon  unit.  The  List  has  an  entry  for  each  entity  declared  and/or  used  in  the  unit,  with  a  few  excepdons 
stated  below.  Overloading  is  evidenced  by  the  occurrence  of  multiple  entries  for  the  same  identifier. 

For  instantiations  of  generic  units  the  visible  declarations  of  the  generic  unit  are  included  in  the  cross-reference 
lifting  as  declared  immediately  after  the  instandadon.  The  visible  declarations  are  the  subprogram  parameters 
for  a  generic  subprogram  and  the  declarations  of  the  visible  part  of  the  package  declaration  for  a  generic  pack¬ 
age. 

For  type  declarations  all  implicitly  declared  operations  are  included  in  the  cross-reference  listing. 
Cross-reference  information  will  be  produced  for  every  constituent  character  literal  for  string  literals. 

The  following  are  not  included  in  the  aoss- reference  listing: 
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•  pragma  idendficrs  and  pragma  argument  identifiers; 

•  numeric  literals; 

•  record  component  identifiers  and  discriminant  idendficrs.  For  a  selected  name  whose  selector  denotes 
a  record  component  or  a  discriminant,  only  the  prefix  generates  cross-reference  informadon; 

•  a  parent  unit  name  following  separate. 

Each  entry  in  the  cross-reference  listing  contains: 

•  the  identifier  with  at  most  IS  characters.  If  the  identifier  exceeds  IS  characters,  a  bar  ('  | ')  is  written 
in  the  16th  posidon  and  the  remaining  characters  are  not  printed; 

•  the  place  of  the  definidon,  Le.,  a  line  number  if  the  entity  is  declared  in  the  current  compiladon  unit, 
othervise  the  name  of  the  compiladon  unit  in  which  the  endty  is  declared  and  the  line  number  of  the 
declaradon; 

•  the  numbers  of  the  lines  in  which  the  endty  is  used.  An  asterisk  (***)  after  a  line  number  indicates  an 
assignment  to  a  variable,  inidalizadon  of  a  constant,  or  assignments  to  funcdons  or  user-defined 
operators  by  means  of  return  statements. 

An  example  of  a  cross-reference  listing  is  shown  in  Chapter  10. 


4J4.  Diagnostic  Messages 

The  Ada  compiler  issues  diagnosdc  messages  to  the  diagnosdc  file  (see  Secdon  4.13).  Diagnosdcs  other  than 
warnings  also  appear  on  sysSoutpoL  If  a  source  text  listing  is  requested,  diagnosdcs  are  also  foimd  embedded 
in  the  list  file  (see  Secdon  4.13). 

In  a  source  listing  a  diagnosdc  message  is  placed  immediately  after  the  source  line  causing  the  message.  Mm- 
sages  not  related  to  a  pardcular  line  are  placed  at  the  top  of  the  listing.  Every  diagnosdc  message  in  the  diag¬ 
nosdc  file  is  followed  by  a  line  indicating  the  corresponding  line  number  m  the  source  text.  The  lines  are 
ordered  by  increasing  source  line  numbers.  Line  number  0  is  assigned  to  messages  not  related  to  any  pardcular 
line.  In  sysSoutput  the  messages  appear  in  the  order  in  which  they  are  generated  by  the  compiler. 

The  diagnosdc  messages  are  classified  according  to  their  severity  and  the  compiler  acdon  taken: 
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Warning:  Reports  a  questionable  construct  or  an  error  that  does  not  influence  the  meaning  of 

the  program.  Warnings  do  not  hinder  the  generation  of  object  code.  Example:  A 
warning  will  be  issued  for  constructs  for  which  the  compiler  detects  that 
CONSTRAlNT_ERROR  will  be  raised  at  runtime. 

Error:  Reports  an  illegal  construa  in  the  source  program.  Compilation  continues,  but  no 

object  code  will  be  generated.  Examples:  most  syntax  errors;  most  static  semantic 
errors. 


Severe  Error:  Reports  an  error  which  causes  the  compilation  to  be  terminated  immediately.  No 
object  code  is  generated.  Example:  a  library  unit  mentioned  by  a  with  clause  is  not 
present  in  the  current  program  library. 

Fatal  Error  Reports  an  error  in  the  Compiler  System  itself.  The  compilation  is  terminated 
immediately  and  no  object  code  is  produced.  InterACT  should  be  infoimed  about  all 
such  errors  (see  Appendix  X).  The  user  may  be  able  to  circumvent  a  fatal  error  by 
correcting  the  program  or  by  replacing  program  constructs  with  alternative  constructs. 
Fatal  errors  are  unlikely  to  affect  program  library  integrity. 


The  detection  of  more  than  a  certain  number  of  errors  during  a  compilation  is  considered  a  severe  error.  The 
limit  is  defined  in  the  configuration  file  (see  Section  4.1.4). 


J.l.  Format  and  Content  of  Diagnostic  Messages 

For  certain  syntactically  incorrect  constructs,  the  diagnostic  message  consists  of  a  pointer  line  and  a  text  line.  In 
all  other  cases  a  diagnostic  message  consists  of  a  text  line  only. 

The  pointer  line  contains  a  pointer  (^)  to  the  offending  symbol  or  to  an  illegal  character. 

The  text  line  contains  the  following  information: 

•  the  diagnostic  message  identification  '****. 

•  the  message  code  XY-Z  where 

X  is  the  message  number 

Y  is  the  severity  code,  a  letter  showing  the  severity  of  the  error 

W:  warning 
E:  error 
S:  severe  error 
F:  fatal  error 

Z  is  an  integer  which  together  with  the  message  number  X  uniquely  identifies  the  compiler 
location  that  generated  the  diagnostic  message.  Z  is  only  useful  for  compiler  maintenance 
purposes 
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The  message  code  (with  the  exceptioo  of  the  severity  code)  is  suppressed  if  the  configuratioa 
file  compoaent  SUPPRESS  ERRORNO  has  the  value  TRUE  (sec  Secoon  4.1,4). 

•  the  message  text.  The  text  may  include  one  context-dependent  field  which  contains  the  name  of  the 
offending  symbol;  if  longer  than  16  charaaers,  only  the  first  16  characters  are  shown. 

Examples  of  diagnostic  messages  are: 

13W-3:  Warning;  Exception  CONSTRAINT_ERROR  will  be  raised  here 
•••  320E-2;  Name  OBJ  does  not  denote  a  type 
***  535E-0:  Expression  in  return  statement  mlvung 
***  LS08S-0;  Specification  for  this  package  body  not  present  in  the  library 

Chapter  10  shows  an  example  program  with  errors  and  the  source  listing  and  diagnostic  file  produced. 


4  J.6.  Generated  Assembly  Listing 

The  generated  assembly  listing  is  the  output  of  the  1750A  Assembler  when  it  assembles  the  generated  IEEE 
assembly  source  produced  by  the  compiler  for  a  compilation  unit.  (The  assembly  takes  place  as  part  of  the 
compile  command.) 

The  Ada  source  text  appears  as  comments  in  the  generated  assembly  code,  with  the  source  text  corresponding 
to  each  Ada  scope  start,  declaration,  statement,  and  scope  end  appearing  before  the  corresponding  generated 
assembly  code.  The  line  number  from  the  Ada  source  file  also  appears  m  these  comments.  If  an  Ada  source 
text  line  is  longer  than  72  characters,  it  is  truncated  with  a  backslash  Q  character  in  the  listing. 

If  the  compilation  unit  contains  generic  instantiations  or  inline  subprogram  calls  where  the  original  Ada  source 
text  is  in  a  different  file  from  the  unit  being  compiled,  the  source  text  is  brought  in  from  that  file  and  a  com¬ 
ment  is  generated  to  indicate  when  that  file  is  being  referenced.  If  an  Ada  source  file  cannot  be  located 
(because  the  user  has  moved  or  deleted  it  since  the  original  compilation,  or  because  it  is  for  a  predefmed  library 
unit),  a  comment  is  issued  to  that  effect,  and  comments  are  interleaved  that  supply  only  the  source  line 
numbers. 

The  compiler  unnests  lexically  nested  subprogram  bodies  and  task  bodies  in  the  generated  code  so  that  they 
appear  textually  after  their  parent  scopes.  The  Ada  source  line  comments  for  these  bodies  do  not  appear  in 
their  lexical  place  in  the  parent  scopes,  but  rather  with  the  unnested  generated  code.  Occasionally  special 
compiler-generated  routines  appear  in  the  generated  code  that  have  no  particular  correspondence  to  the  Ada 
source.  A  comment  is  issued  to  this  effect  when  this  happens. 

In  addition  lo  the  interleaved  Ada  source,  comments  at  the  beginning  of  the  assembly  listing  indicate  the  source 
flic  name  that  this  compilation  unit  came  from,  the  compilation  unit  name,  and  the  sublibrary  file  name  that  it 
is  bi  ing  compiled  into. 

The  bottom  of  the  generated  assembly  listing  shows  the  object  code  sizes  of  the  compilation  unit. 

Note  that  laocls  and  external  names  in  the  assembly  listing  often  refer  to  program  unit  numbers,  rather  than  (or 
in  addition  to)  unit  names;  if  necessary,  correspondence  can  be  established  through  use  of  Ada  PLU  (see 
Chapter  3). 
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4J.7.  Return  Status 

After  a  compilation  the  VAX/VMS  DCL  symbols  Sstatus  and  Sseverity  will  reflect  whether  the  compilation 
was  successful  The  possible  values  of  Sseverity  and  the  low-order  bits  of  Sstatus  are  1  (success)  or  2  (error). 


4.4.  The  Program  library 

This  section  briefly  describes  how  the  Ada  compiler  changes  the  program  library.  For  a  more  general  descrip¬ 
tion  of  the  program  ITorary,  see  Chapter  2. 

The  compiler  is  allowed  to  read  from  all  sublibraries  constituting  the  current  program  library,  but  only  the 
current  sublibrary  may  be  changed. 


4.4J.  Correct  Compilation 

In  the  following  examples  it  is  assumed  that  the  compilation  units  are  correctly  compiled,  i.e.,  that  no  errors  are 
detected  by  the  compiler. 

Compilation  of  a  library  unit  which  is  a  declaration 

If  a  declaration  unit  of  the  same  name  exists  in  the  current  sublibrary,  it  is  deleted  together  with  its  body  unit 
and  possible  subunits.  A  new  declaration  unit  is  inserted  in  the  sublibrary,  together  with  an  empty  body  unit. 

Compilation  of  a  library  unit  which  is  a  subprogram  body 

A  subprogram  body  in  a  compilation  unit  is  treated  as  a  secondary  unit,  if  the  current  sublibrary  contains  a  sub¬ 
program  declaration  or  a  generic  subprogram  declaration  of  the  same  name  and  this  declaration  unit  is  not 
invalid. 

In  all  other  cases  it  will  be  treated  as  a  library  unit,  Le.: 

•  when  there  is  no  library  unit  of  that  name; 

•  when  there  is  an  invalid  declaration  unit  of  that  name; 

•  when  there  is  a  package  declaration,  generic  package  declaration,  or  an  instantiated  package  or  sub¬ 
program  of  that  name. 

Compilation  of  a  library  unit  which  is  an  instandatioo 

A  possible  existing  declaration  unit  of  that  name  in  the  current  sublibrary  is  deleted  together  with  its  body  unit 
and  possible  subunits.  A  new  declaration  unit  is  inserted. 

Compilation  of  a  secondary  unit  which  is  a  library  unit  body 

The  existing  body  is  deleted  from  the  sublibrary  together  with  its  possible  subunits.  A  new  body  unit  is  inserted. 
Compilation  of  a  secondary  unit  which  is  a  subunit 

If  the  subunit  exists  in  the  sublibrary,  it  is  deleted  together  with  its  possible  subunits.  A  new  subunit  is  inserted. 
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4.42.  Incorrect  CompUadons 

If  the  compiler  detects  an  error  in  a  compilation  unit,  the  program  library  will  be  kept  unchanged. 

If  a  source  Hie  consists  of  several  compilation  units  and  an  error  is  detected  in  any  of  these  compilation  units, 
the  program  library  will  no(  be  updated  for  any  of  the  compilation  units. 

4S.  Instandadon  of  Generic  Units 


4J.1.  Order  of  Compiladon 

When  instantiating  a  generic  unit,  it  is  required  that  the  entire  unit  including  body  and  possible  subunits  is  com¬ 
piled  before  the  first  instantiation  or  -  at  the  latest  -  in  the  same  compilation.  This  is  in  accordance  with  [Ada 
RM  10.3]. 


4,5,2.  Generic  Formal  Private  Types 

This  section  describes  the  treatment  of  a  generic  unit  with  a  generic  formal  private  type,  where  there  is  some 
construa  in  the  generic  unit  that  requires  that  the  corresponding  actual  type  must  be  constrained  if  it  is  an  array 
type  or  a  type  with  discriminants,  and  instantiations  exist  with  such  an  unconstrained  type  [Ada  RM  12.3.2(4)]. 

This  is  considered  an  illegal  combination.  In  some  cases  the  error  is  detected  when  the  instantiation  is  com¬ 
piled,  in  other  cases  when  a  constraint-requiring  construct  of  the  generic  unit  is  compiled: 

1.  If  the  instantiation  appears  in  a  later  compilation  unit  than  the  first  constraint-requiring  construa  of 
the  generic  unit,  the  error  is  associated  with  the  instantiation  which  is  rejeaed  by  the  compiler. 

2.  If  the  instantiation  appears  in  the  same  compilation  unit  as  the  first  constraint-requiring  construa  of 
the  generic  unit,  there  are  two  possibilities: 

(a)  If  there  is  a  constraint-requiring  construa  of  the  generic  unit  after  the  instantiation,  an  error 
message  appears  with  the  instantiation. 

(b)  If  the  instantiation  appears  after  all  constraint-requiring  constructs  of  the  generic  unit  in  that 
compilation  unit,  an  error  message  appears  with  the  constraint-requiring  construct,  but 
refers  to  the  illegal  instantiation. 

3.  The  instantiation  appears  in  an  earlier  compilation  unit  than  the  first  constraint-requiring  construa  of 
the  generic  unit,  which  in  that  case  appears  in  the  generic  body  or  a  subunit.  If  the  instantiation  has 
been  accepted,  the  instantiation  corresponds  to  the  generic  declaration  only,  and  does  not  include  the 
body.  Nevertheless,  if  the  generic  unit  and  the  instantiation  are  located  in  the  same  sublibrary,  then 
the  compiler  considers  it  an  error.  An  error  message  is  issued  with  the  constraint-requiring  construa 
and  refers  to  the  illegal  instantiation.  The  unit  containing  the  instantiation  is  not  changed,  however, 
and  is  not  marked  as  invalid. 


LINKER  OPTIONS 


The  linker  options  of  this  Ada  implementation,  as  described  in  this 
Appendix,  are  provided  by  the  customer.  Unless  specifically  noted 
otherwise,  references  in  this  appendix  are  to  linker  documentation  and 
not  to  this  report. 
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Before  a  compiled  Ada  program  can  be  executed  it  must  be  linked  into  a  load  module  by  tke  Ada  Linker. 

A  single  program  may  be  linked  for  either  a  non-erpanded  memory  1750A  configuration,  or  for  any  <17^  of 
expanded  memory  1750A  configuration. 

In  its  normal  and  conventional  usage,  the  Ada  Linker  links  a  single  Ada  program. 

The  Ada  Linker  also  has  the  capability  to  link  multiple  Ada  programs  into  one  load  module,  where  the  pro¬ 
grams  will  execute  concurrently.  This  capability,  which  is  outside  the  definition  of  the  Ada  language,  is  called 
multiprogramming,  and  is  further  discussed  below. 

The  Ada  link,  while  one  command,  can  be  seen  as  having  two  parts:  an  "Ada  part"  and  a  ’HSOA  part*. 

The  Ada  part  performs  the  link-time  functions  that  are  required  by  the  Ada  language.  This  mcludes  checking 
the  consistency  of  the  library  units,  and  constructing  an  elaboration  order  for  those  library  units.  Any  errors 
found  in  this  process  are  reported. 

To  effect  the  elaboration  order,  the  Ada  link  constructs  an  assembly  language  ’elaboration  caller  routine’  that  is 
assembled  and  linked  into  the  executable  load  module.  This  is  a  smaD  routine  that,  during  execution,  gets  con¬ 
trol  from  the  Ada  runtime  executive  initiator.  It  invokes  or  otherwise  marks  the  elaboration  of  each  Ada  library 
unit  in  the  proper  order,  then  returns  control  to  the  runtime  executive,  which  in  txum  invokes  the  main  program. 
The  action  of  the  elaboration  caller  routine  is  transparent  to  the  user. 

If  no  errors  are  found  in  the  Ada  part  of  the  link,  the  1750A  part  of  the  link  takes  place.  This  consists  of  assem¬ 
bling  the  elaboration  caller  rootine,  then  invoking  the  InterACTT  175QA  Linker,  linking  the  program  unit  object 
modules  (stored  in  the  program  library)  and  the  elaboration  caller  routine  together  with  the  necessary  parts  of 
the  Ada  runtime  executive  (and  some  other  rtmtime  modules  needed  by  the  generated  code).  The  output  of  the 
full  Ada  link  is  an  executable  load  module  file. 

The  invocations  of  the  1750A  Assembler  and  Linker  are  transparent  to  the  user.  However,  qualifiers  on  the 
Ada  link  command  allow  the  user  to  specify  additional  information  to  be  used  in  the  target  link.  Through  this 
facility,  a  wide  variety  of  runtime  executive  optional  features,  customizations,  and  user  exit  routines  may  be 
introduced  to  guide  or  alter  the  execution  of  the  program.  These  are  described  in  the  Ada  175QA  Runtime  Exe¬ 
cutive  Prograryuner's  Guide.  This  facility  may  also  be  used  to  modify  or  add  to  the  standard  1750A  Linker  control 
statements  that  are  used  in  the  1750A  part  of  the  link;  in  this  way,  target  memory  may  be  precisely  defined. 
The  control  statements  involswl  are  described  in  the  InterACT  175QA  Assembler  and  Linker  User’s  Manual. 
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Expanded  Memory 

Expanded  memory  is  an  optional  hardware  feature  of  the  1750A.  Without  the  expanded  memory  option,  the 
1750A  interprets  16-bit  addresses  as  physical  addresses,  thereby  allowing  a  maximum  memory  space  of  64K 
words.  With  the  expanded  memory  option,  the  1750A  can  address  up  to  IM  words  of  memory  by  maintaining  a 
set  of  page  tables  which  enable  it  to  translate  16-bit  logical  addresses  into  20-bit  physical  addresses.  (This  IM 
of  memory  can  be  divided  into  any  ratio  of  code  to  data.  Some  implementations  of  1750A  map  instruction  and 
data  fetches  into  separate  physical  hardware  areas,  resulting  in  up  to  2M  words  of  memory  being  available  - 
IM  of  code,  IM  of  data.) 

However,  since  the  175QA  is  fundamentally  a  16-bit  processor,  it  does  not  allow  direct  access  to  the  entire  IM 
address  space.  Instead,  it  defmes  up  to  16  ’contexts*  known  as  address  susses,  only  one  of  which  may  be  active  at 
any  moment  Each  address  state  consists  of  a  logical  memory  space  containing  up  to  64K  of  code  and  64K  of 
data. 

To  a  large  degree,  the  difficulties  involved  in  working  with  17S0A  expanded  memory  stem  from  one  question: 
which  code  and  data  go  in  which  address  suae?  This  is  because  jumping  from  one  address  state  to  another, 
known  as  context  switching,  is  an  expensive  operation  for  real-time  applications  if  done  indiscriminately.  Con¬ 
sequently,  the  decision  concerning  what  to  place  in  each  address  state  is  best  left  to  the  system  designer.  Once 
that  decision  is  made,  the  Compiler  System  automates  the  rest  of  the  process. 

These  address  state  bindings  are  done  at  Ada  link  time.  The  user  spcdfies  a  main  program,  which  will  reside  in 
address  state  0,  and  any  number  of  'top-level*  compilation  units,  which  will  reside  in  address  states  spedfied  by 
the  user.  Calls  to  any  subprograms  defmed  within  these  top-level  units  (and  the  elaboration-time  call  to  the 
unit  itself)  will  be  made  via  the  Long  Call  facliry. 

The  Long  Call  facility  allows  a  subprogram  residing  in  one  address  state  to  call  a  subprogram  residing  in 
another  address  state.  The  actual  call  and  return  is  handled  automatically  by  the  Compiler  System.  (The 
implementation  consists  of  the  1750A  linker  replacing  call  and  return  instructions  with  branch-to-executive 
instructions,  through  which  th^  Ada  runtime  executive  performs  a  context  switch  using  tables  set  up  by  the 
17S0A  Linker.)  Passed  parameters,  including  those  passed  by  reference  (arrays  and  records),  are  also  handled 
automatically.  Thus,  inter-address  state  calls  look  no  different,  in  the  Ada  source,  than  intra-address  state  calls, 
and  there  are  no  restrictions  on  such  calls. 

The  Ada  runtime  executive  also  automatically  handles  task  rendezvous  across  address  states;  thus  an  entry  call 
may  also  involve  a  context  switch,  if  the  user  has  designated  the  compilation  unit  containing  the  task  to  reside  in 
a  different  address  state  from  the  calling  task. 

All  units  other  than  those  spedfied  by  the  user  as  'long  called*,  automatically  reside  in  every  address  state  that 
references  them.  (The  implementation  consists  of  the  17SQA  Linker  setting  up  page  register  tables  that  reflect 
this  mapping,  and  the  Ada  runtime  executive  loading  these  page  registers  during  initialization  processing) 
Thus,  calk  to  these  units,  and  references  to  their  data,  have  no  extra  execution-time  cost  associated  with  them. 

In  addition  to  user-spedfied  address  states’  contents,  the  Compiler  System  automaticaUy  indudes  in  each 
defmed  address  state  (Le.  makes  globally  shareable)  the  Ada  runtime  system,  induding  the  system  heap  and  the 
stacks  for  the  main  program  and  all  tasks. 

To  summarize  the  memory  capabilities  of  single  program  expanded  memory  support,  a  program  linked  for 
expanded  memory  may  contain  up  to  IM  of  code.  The  program’s  local  objects  and  access  object  space  is  limited 
to  64K.  The  program’s  library  package  objects  (Le.,  objects  with  static  allocation)  may  occupy  more  than  64K, 
with  no  context  switch  overhead,  to  the  extent  that  they  arc  referenced  in  only  some  address  states. 

As  an  illustration,  consider  a  simple  application  consisting  of  6  library  units:  a  main  program  ni^t_simuIator, 
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and  packages  operations  a,  operations  b,  operations  c,  utilities,  and  efTor_haDdler.  The  follov^ing  diagram 
portrays  the  relationship  between  the  units. 


night_simulator 


f  ■>\ 

opcrations_a  operations_b  operations_c 


error  handler  utilities 


The  arrows  represent  dependencies  (i.e.  "with*  clauses).  Thus,  fight  simulator  calls  subprograms  (or  task 
entries)  in  the  operations  packages,  all  of  which  make  use  of  error  handler.  In  addition,  each  of  the  opera¬ 
tions  makes  use  of  a  unit  named  ntilities. 

The  system  designer  knows  the  application  requires  more  than  MK  of  physical  memory,  thus  the  expanded 
memory  option  must  be  used.  Units  might  be  assigned  to  address  states  as  follows; 


address  state  0 

fHght  simulator 
(opcrations_a) 
(opcrations_b) 
(opcrations_c) 


address  state  1 

operations  a 

error_han<llcr 

utilities 


address  state  2 

operations  b 
operations  c 
(error  handler) 
utilities 


The  units  in  parentheses  indicate  units  not  actually  resident  in  the  listed  address  state  but  referenced  via  the 
long  call  facility.  Thus,  address  state  0  contains  only  flght^simulator  which  makes  long  calls  to  the  operabons. 
Address  state  1  contains  operatioas  a,  utilities,  and  error  handler.  And  address  state  2  contains  operations  b 
and  operatioas_c  whicn  make  long  c.alls  to  error  handler,  and  ordinary  calls  to  utilities. 

Note  that  both  eiTor_handler  and  utilities  arc  accessed  in  address  states  1  and  2.  But  whereas  utilities  actually 
resides  in  both  address  states  (Le.  one  physical  instance  mapped  into  both  address  states),  error  handler 
resides  only  in  address  state  1. 

Multiprogramming 

As  stated  above,  multiprogramming  is  the  capability  of  linking  multiple  Ada  programs  into  one  load  module, 
where  the  programs  will  execute  conciurently.  As  this  concept  is  outside  the  definiuon  of  the  Ada  language,  the 
discussion  of  mulbprogramming  here  is  speciric  to  this  Qjmpilcr  System’s  implemcntaUon. 

In  multiprogramming,  Ada  units  (comprising  code,  literals,  and/or  data)  that  arc  common  to  more  than  one 
program  arc  linked  but  once,  and  arc  shared  by  those  programs.  With  respect  to  code  and  literals,  this  has  no 
effect  upon  exccubon,  and  results  in  more  efficient  memory  utilization.  However,  with  respea  to  data,  this 
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means  that  the  actions  of  one  Ada  program  can  affect,  and  possibly  cause  erroneous  behavior  in,  another  Ada 
program.  Such  an  interaction  may  be  desired,  as  m  the  case  of  a  common  library  package’s  data  being  used  to 
communicate  between  programs.  If  such  an  interaction  is  not  desired,  the  program  units  that  would  otherwise 
be  common  may  be  rewritten  as  generic  units,  and  instantiated  with  a  different  name  for  each  program  that  uses 
them. 

Elaboration  of  common  »tnits  is  only  done  once,  by  the  ‘first*  program  that  depends  on  them.  This  ordering  is 
defined  by  the  order  in  which  the  programs  are  named  to  the  Ada  link  command  (and  not  by  their  address  state 
order,  if  an  expanded  memory  link  is  being  done). 

In  order  to  ensure  that  units  are  elaborated  before  being  referenced,  the  runtime  executive  elaborates  the  units 
of  each  program  serially,  waiting  for  the  elaborations  for  one  program  to  finish  before  going  on  to  the  next 
program’s  elaborations.  When  all  elaborations  have  completed,  the  main  programs  themselves  are  eligible  to 
execute.  Programs,  and  any  tasks  within  them,  are  scheduled  by  their  Ada  priority  on  a  global  basis.  See  the 
Ada  17SQA  Runtime  Executive  Propammer’s  Guide  for  more  details  on  this  process,  and  on  the  criteria  by  which 
programs  are  scheduled  and  dispatched. 

The  main  programs  involved  in  a  multiprogramming  link  must  all  be  present  within  the  same  program  library. 

Multiprogramming  m'v  be  done  on  either  a  non-expanded  memory  or  an  expanded  memory  1750A 
configuration.  In  the  latter  it  is  used  in  conjunction  with  the  single  program  expanded  memory  linking 
features  described  above.  One  or  more  programs  may  be  defmed  to  an  address  state. 

Note  that  it  is  not  necessary  to  use  multiprogramming  to  take  advantage  of  a  1750A  expanded  memory 
configuratioa  Multiprogramming  is  often  best  suited  towards  real-time  ‘operating  systems'  implemented  in 
Ada,  where  each  application  running  under  the  operating  system  is  represented  as  an  Ada  main  program,  and 
where  communication  requirements  among  the  programs  are  minor  or  absent. 


5.1.  The  Invocation  Command 

The  Ada  Linker  is  invoked  by  submitting  the  following  VAX/VMS  command: 


S  adal750/Mak{qualifier}  main-programs  [long<aUed-units] 

main-programs ::  =  main-program-name  (sin^e  program  link) 

I  {main-program-name {/ms-qualifier  |  /optiota-quaJifier)]  (multiprogramming  link) 

long-caJled-uniLs  {unit-name[/is-quaJifier]} 


As  part  of  the  ‘1750A  part*  of  an  Ada  link,  a  temporary  subdirectory  is  created  below  the  current  default  direc¬ 
tory.  Use  of  this  subdirectory,  the  name  of  which  is  constructed  from  the  VAX/VMS  process-id,  permits  con¬ 
current  linking  in  the  same  current  default  directory.  The  subdirectory  contains  work  files  only,  and  it  and  its 
contents  are  deleted  at  the  end  of  the  link. 

A  consequence  of  the  use  of  this  subdirectory  is  that  an  Ada  link  cannot  be  done  from  a  current  default  direc¬ 
tory  that  is  eight  directory  levels  deep,  as  that  is  the  VAX/VMS  limit  for  directory  depth. 

Infrequently,  a  controi-C  or  control-Y  interrup,  of  an  Ada  link  will  leave  the  subdirectory  present.  If  this  hap¬ 
pens,  the  subdirectory  and  its  contents  must  be  deleted,  in  order  that  subsequent  links  (by  iLat  process,  m  that 
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current  default  directory)  may  take  place. 


5.1.1.  Parameters  and  Qualifiers 

Default  values  for  aU  qualifiers  as  indicated  below.  All  qualifier  names  may  be  abbreviated  (characters 
omitted  from  the  right)  as  long  as  no  ambiguity  arises. 

main-prog^vm-name 

If  a  program  link  is  being  done,  main-propam-fiame  must  specify  a  main  program  which  is  a  library  unit 
of  the  current  program  library,  but  not  necessarily  of  the  current  sublibrary.  The  library  unit  must  be  a  parame- 
terless  procedure.  Note  that  main-proprim-name  a  the  identifier  of  an  Ada  procedure;  it  is  not  a  VAX/VMS 
file  spe^catioiL 

When  main-p/ogram-name  is  used  as  the  file  name  in  Ada  link  output  (for  the  load  module,  memory  map  Gle, 
etc.),  the  file  name  will  be  truncated  to  29  characters  if  necessary. 

If  a  multiprogramming  link  is  being  done,  multiple  main-propam-names  are  specified,  separated  by  commas. 
The  first  name  supplied  is  the  one  used  for  the  file  name  in  Ada  link  output. 

The  first  three  of  the  qualifiers  below  pertain  to  the  'Ada  part*  of  the  Ada  link.  The  remaining  qualifiers  per¬ 
tain  to  the  '175QA  part"  of  the  link. 

/\ogl  X file-spec] 

/nolog  (default) 

The  qualifier  specifies  whether  a  log  file  is  to  be  produced  during  the  linking.  By  default  no  log  file  is  pro¬ 
duced.  If  /log  is  specified  without  a  file  specification,  a  log  file  named  main-program-name  Jog  is  created 
in  the  current  default  directory.  If  a  file  spedficadon  is  given,  that  file  is  created  as  the  log  file.  The  contents  of 
the  log  file  are  described  in  Section  53. 

/library  =  file-spec 

/]ibnry=ada]750Jibrary  (default) 

This  qualifier  specifies  the  current  sublibrary  and  thereby  also  the  current  program  library,  which  consists  of  the 
current  sublibrary  through  the  root  sublibrary  (see  Chapter  2).  If  the  qualifier  is  omitted,  the  sublibrary  desig¬ 
nated  by  the  logical  name  adal750_Ubnry  is  used  as  current  sublibrary. 

/mp 

This  qualifier  specifies  that  a  multiprogramming  link  be  done.  By  default  a  single  program  link  is  done. 

/as[  ^address-state] 

This  qualifier  is  used  in  two  contexts.  It  must  be  used  after  the  Ada  link  command  verb  to  indicate  that  an 
expanded  memory  link  be  done  (whether  single  program  or  multiprogramming).  By  default  a  non-expai>ded 
memory  link  is  done.  In  this  context  it  is  used  without  an  address-state  value. 


If  a  single  program  expanded  memory  link  is  being  done,  this  qualifier  is  also  used  after  each  long<alled-uni:,  to 
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specify  the  address  state  that  unit  will  reside  in. 

If  a  muloprogramming  link  is  being  done,  this  qualifier  may  be  used  after  each  mam-program-name,  to  specify 
the  address  state  that  program  will  reside  in.  However,  if  the  qualifier  is  not  used  after  any  mam-program- 
names,  the  programs  are  assigned  by  the  Ada  link  to  address  states  in  their  order  of  appearance,  one  per 
address  state,  starting  with  address  state  0. 

/options  [  *mac7t>-name] 

This  quaHfier  is  used  to  override  certain  default  values  that  are  used  by  the  Ada  runtime  executive.  If  the 
qualifier  is  omitted,  no  overriding  takes  place. 

The  quahfier  specifies  the  name  of  an  assembly  language  macro  containing  one  or  more  conditional  assembly 
directives  that  override  the  default  values  of  certain  assembly-time  symbols.  (Note  that  this  is  a  macro  name, 
not  a  VAX/VMS  file  name.)  If  /options  is  specified  without  a  macro-name,  mam-program-name  is  used  as  the 
macro  name. 

The  names  of  these  assembly-time  symbols,  their  default  values,  and  the  runtime  behavior  that  they  control,  arc 
described  in  the  Ada  17SQA  Runtime  Executive  Programmer's  Guide.  A  macro  file  containing  the  definition  of 
this  macro  must  be  available  to  the  175QA  Assembler  at  the  time  of  the  link  by  one  of  the  means  documented  in 
the  InterACr  17SQA  Assembler  and  Linker  User’s  Manual. 

If  a  multiprogramming  link  is  done,  the  /options  qualifier  may  appear  either  after  the  Ada  link  command  verb, 
in  which  case  it  applies  to  every  program  being  linked  (or,  if  no  macro-name  is  given,  each  main-program-name 
default  applies  to  each  program  ^ing  linked),  or  it  may  appear  after  some  or  all  of  the  main-program-names,  in 
which  case  it  applies  to  only  those  programs  (and  supercedes  for  those  programs  a  /options  qualifier  used  after 
the  command  verb,  if  any). 

/staodard_^coaCroi(  =  file-spec] 

/standard  control =adalink  standard_control  |  adalink_expmem_coatrol  (default) 

This  qualifier  specifies  the  file  name  of  'standard'  17SQA  Linker  control  statements  that  are  to  be  used  for  all 
links  for  an  installation  or  project.  If  fUe-spec  is  omitted  or  only  partially  specified,  [  ladallnkJod  is  used  as  a 
full  or  partial  default.  If  the  qualifier  is  omitted,  the  logical  name  adalink_standard_coatrol  or 
adalink  expmem  control  (if  an  expanded  memory  link  is  being  done)  is  assumed  to  define  such  a  file,  using  the 
same  partial  default.  If  that  logical  name  is  not  defined  or  the  specified  file  does  not  exist,  no  standard  control 
statements  are  used. 

/control{  =  file-spec] 

This  qualifier  specifies  the  file  name  of  'user'  17S0A  Linker  control  statements  that  are  to  be  used  for  this  par¬ 
ticular  link.  If  file-spec  is  omitted  or  only  partially  spedfied,  [  \rrutin-proffam-ruimelod  is  used  as  a  full  or  par¬ 
tial  default  If  the  qualifier  is  omitted  or  the  specified  file  does  not  exist,  no  user  control  statements  are  used. 

The  files  designated  by  the  /standard_coDtrol  and  /control  qualifiers  are  used  to  form  the  full  input  control 
statement  stream  to  the  175QA  Linker,  m  this  concatenated  order. 

/standard_control  file  (if  it  exists) 

<  sutements  generated  by  the  Ada  part  of  the  link  > 

/control  file  (if  qualifier  active  and  it  exists) 
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The  generated  by  the  Ada  part  of  the  link  are  usually  just  SELECT  or  ADDRSTATE  statements  for 

the  elaboration  caller  routine(s)  and  main  program(s). 

The  Compiler  System  is  delivered  vvith  adallnk_standard_cootrol  and  adallnk_apmem_controi  defmed  to 
files  that  contain  default  sets  of  standard  control  statements.  These  consist  of  the  minimal  SECTION  state¬ 
ments  required  by  the  175QA  Linker,  and  various  other  necessary  directives. 

/user_rts = search-list 

/iiser_rts=adalink_nser_rts  (default) 

This  qualifier  specifies  a  VAX/VMS  search  list  that  contains  either  user-dependent  RTE  modules,  such  as  a 
fJiange  to  the  task  scheduler  for  a  particular  application,  or  pragma  INTERFACE  (ASSEMBLY)  bodies  for 
subprograms  that  are  not  library  units  (see  Section  F2).  Modules  in  this  search  list’s  directory(ies)  are  taken 
ahead  of  those  in  the  directories  specified  by  /target_rts  (see  below)  and  those  in  the  standard  RTE  directory. 
If  the  qualifier  is  omitted,  logical  name  adiJink_user_rts  is  used,  if  the  name  has  been  defined. 

/target_rts -search-list 

/target_rts  =  adalink_target_rts  (default) 

This  qualifier  specifies  a  VAX/VMS  search  list  that  contains  17S0A-implcmentation(target)-dependent  runtime 
executive  (RTE)  modules,  such  as  modules  to  do  character  I/O  for  a  particular  simulator  or  microprocessor. 
Modules  in  this  search  list’s  directory(ies)  are  taken  ahead  of  those  in  the  standard  RTE  directory.  If  the 
qualifier  is  omitted,  logical  name  adalink_target_rts  is  used,  if  the  name  has  been  defmed.  Note  however  that 
if  pragma  NO_DYNAMIC_OBJECTS_OR_VALUES_USED  is  spedfied  (sec  Section  F3),  this  qualifier  has 
no  effect. 

/debug 

/nodcbug  (default) 

When  this  qualifier  is  given,  the  Ada  Linker  will  produce  a  symbolic  debug  information  file,  containing  symbolic 
debug  information  for  ail  program  units  involved  in  the  link  that  were  compiled  with  the  /debug  compiler 
qualifier  active.  By  default  no  such  file  is  produced,  even  if  some  of  the  program  units  linked  were  compiled 
with  /debug  active. 

This  symbolic  debug  information  file  is  used  by  the  InterACT  Symbolic  Debugging  System. 

The  show/containen  command  of  Ada  PLU  may  be  used  to  determine  which  units  in  the  program  library  have 
debug  information  containers,  Le.,  which  units  were  compiled  with  /debug  active. 

It  is  important  to  note  that  the  identical  executable  load  module  is  produced  by  the  Ada  Linker,  whether  or  not 
the  /debug  qualifier  is  active. 

/actlnk^qualiflen  =  *17SQA  Linker  qualifiers' 

This  qualifier  specifies  a  string  containing  one  or  more  command  qualifiers  to  be  passed  to  the  execution  of  the 
1750A  Linker. 

/stop  (= number] 

This  qualifier,  when  used  with  no  number,  results  in  the  Ada  link  stopping  after  the  'Ada  part*  has  done  all 
Ada-required  checking,  and  has  aeated  a  VAX/VMS  DCL  command  file  (located  in  the  temporary 
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subdirectory)  that  executes  the  *175QA  part*,  but  before  that  command  file  has  actually  been  invoked. 

When  used  with  number  >  1,  the  command  file  is  invoked,  but  stops  before  the  17SQA  Linker  is  invoked,  leav¬ 
ing  the  temporary  subdirectory  and  its  files  in  place.  When  used  with  number  «  2,  it  executes  the  17SQA  Linker 
but  then  stops  before  the  symbolic  debug  information  file  is  produced. 

This  qualifier  is  useful  for  trouble-shoodng,  or  for  giving  the  user  an  intervention  point  for  Ada  link  customiza- 
tions  not  covered  by  any  of  the  available  options. 


5A2.  Examples 

A  single  program,  64K  memory  link: 

$  adal750/link  flgbt_simalator 
A  single  program  link  for  128K  expanded  memory; 

$  adal750/Iink/as  fEght_simulator 

In  the  above  case,  no  long  called  units  are  necessary  since  only  one  address  state  is  being  used.  Now  an  exam¬ 
ple  of  a  single  program,  greater  than  128K  expanded  memory  link,  where  long  calk  are  necessary,  for  the  illus¬ 
tration  presented  at  the  beginning  of  this  Chapter. 

S  adal750/link/as  flght^simulator  operations_a/BS=l,eiTor_handler/assl,- 

operations^b/as = 2,operations_c/as  s  2 

Some  multiprogramming  examples,  with  64K  and  then  expanded  memory; 

$  adal750/llnk/mp  able,baker,charUe 

S  adal750/Unk/mp/as  able4>aker,charlk 

$  adal750/1ink/mp/as  able/as  s04>aker/as  =  l,chariic/as= 2 

The  last  two  examples  above  are  equivaleaL  However,  the  following  sort  of  assignment  can  only  be  done  i«ing 
the  second  form: 

$  adal750/liiik/mp/as  able/as =Od>aker/as=l,chariic/as  =  l,dog/ass  4 

Now,  an  example  of  overriding  default  runtime  executive  values,  in  this  case  the  system  heap  size  and  main 
stack  size: 

$  adal750/link/opt  night_simulator 

where  flght^simulatorjnac  in  the  current  directory  contains 
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FLIGHT_SIMULATOR  NAC80 
I  HEAP  SIZE  '  ASET  24*1024 
IMAINiTACX.SIZE  ASET  8*1024 
EHDMAC 

Some  examples  of  overriding  values  when  multiprogramming  is  involved: 

$  adal750/link/mp/as/optslarge_stack  able4iakcr,c!iarUc 

would  use  large_stackjnac  for  aD  three  programs,  «diile 
$  adal750/llnk/mp/as/opt  ablejbaker,diarlie 

would  use  abieunac,  baker  jnac,  and  charliejnac  for  the  three  programs  respectively.  Ahematively, 

$  adal750/Iink/mp/as/opt=Iarge_stack  able,baker/opt  -  sinall_stack,f  hariie 

would  use  large  stackmac  for  ABLE  and  CHARLIE,  but  use  smaU^staclunac  for  BAKER,  while 
S  adal750/Iink/mp/as  ableiiaker/opLchariie 

would  use  baker  jnac  for  BAKER,  and  all  default  values  for  ABLE  and  CHARLIE. 

Now,  an  example  of  introducing  ’user*  175QA  Linker  control  statements: 

$  adal750/link/control  test_^driver 

where  test_driver  Jod  in  the  cunent  directory  contains 
PAGE SIZE  60 

SELECT  C<aiw.object]OMACHEU 
NOLOAO 

Note  that  the  SELECT  statement  specifies  the  direaory  where  the  object  module  dmacfaeduic  is  located. 
Now,  an  example  of  the  use  of  user  and  target  RTE  direaories: 

$  define  adalink_target_rts  [tektroaicsJo.test],(tektn>nicsJo] 

S  adal750/Unk/uscr_rt5=sysSascn[teststor_mgr]  flgfat_siJiiulator 

Runtime  executive  modules  will  be  looked  for  in  the  directory  spedfied  by  the  /oscr  rts  qualifier,  then  in  the 
two  directories  specified  by  the  adalink_target  rts  logical  name,  and  lastly  in  the  standard  RTE  directory. 

To  revert  to  referencing  only  the  standard  RTE  directory; 

$  deassign  adalink_target_rts 

S  adal750/1ink  nigfat_simulator 
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52.  Load  Module  Oatpot 

If  an  Ada  Hnlring  IS  snccessfoily  completed,  the  175C)A  Laiker  produces  an  executable  load  module  file  named 
mam-proffam-namt.Mbi%  in  the  current  default  directory. 

The  load  module  is  in  IntezACT  load  module  format,  which  may  require  further  reformatting  before  being 
loaded  into  175QA  hardware  or  simulators  (see  Chapter  8). 


SJJ.  Symbolic  Debug  Infannadon  Output 

If  an  Ada  linlring  with  the  /(febng  qualifier  active  is  successfully  completed,  a  symbolic  debug  information  file 
named  nuan~proffam-nameA  is  created  in  the  current  default  directory.  This  file  is  used  by  the  InterACT  Sym¬ 
bolic  Debugging  System. 


SJ.  Linker  Thzt  Output 

The  Ada  Linker  produces  the  following  text  output: 

1.  Diagnostic  messages  other  than  warnings  arc  written  to  sysSoutput,  and  ail  messages  are  written  to 
the  log  file  if  /log  is  active. 

2.  An  elaboration  order  list  is  written  to  the  log  file  if  /log  is  active. 

3.  A  required  recompilations  list  is  written  to  sysSoutput  if  not  empty,  and  to  the  log  file  if  /log  is  active. 

4.  A  linlring  summary  is  written  to  the  log  file  if  /log  is  active. 

5.  A  175QA  Linker  memory  map  file,  main-proffxim-nam<Jiap.  (See  the  InterACT  175QA  Assembler  and 
Linker  User's  Manual  for  contents.) 

6.  An  assembly  li«aing  of  the  generated  module  that  elaborates  all  library  units,  eSmain-program- 
name.als.  If  a  muitiprogramming  link  is  done,  separate  listings  are  produced  for  each  program. 

7.  If  a  multiprogramming  link  is  done,  an  assembly  listing  of  a  generated  module  that  communicates 
program  information  to  the  Ada  runtime  executive,  SmpLals. 

Note  that  the  log  file  contains  information  relevant  to  the  *Ada  part’  of  the  link,  while  the  memory  map  file 
contains  information  relevant  to  the  ’175QA  part’  of  the  link. 


3J.  Dfagpostk  Messages 

The  Ada  Linker  may  issue  two  kinds  of  diagnostic  messages,  warnings  and  severe  errors. 

A  warning  reports  something  which  does  not  prevent  a  successful  linking,  but  which  might  be  an  error.  A  warn¬ 
ing  is  issued  if  the  body  unit  is  invalid  or  is  lacking  an  object  code  container  for  a  program  unit  which  formally 
does  not  need  a  body.  The  linking  summary  on  the  log  file  contains  the  total  number  of  warnings  issued. 

A  severe  error  message  reports  an  error  which  prevents  a  successful  linking.  Any  mconsistency  detected  by  the 
linker  will  cause  a  severe  error  message,  e.g.,  if  some  required  unit  does  not  exist  in  the  library  or  if  some  time 
stamps  do  not  agree. 
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Examples  of  diagnostic  messages  from  the  Ada  Linker  can  be  found  in  Chapter  10. 


S32.  Elaboration  Order  List 

The  elaboration  order  list  contains  an  entry  for  each  onit  included,  and  shows  the  order  in  which  the  units  wiD 
be  elaborated.  For  each  unit  the  unit  type,  the  compilation  dme,  and  the  dependencies  are  shown.  Further¬ 
more,  any  elaboration  inconsistencies  are  reported 

When  a  multiprogramming  link  is  done,  the  elaboration  order  lists  will  contain  the  full  elaboration  order  of 
each  program,  without  regard  to  multiprogramming.  These  orders  can  be  compared  to  the  elaboration  caller 
assembly  listing  for  a  program,  to  see  v^ch  elaborations  were  omitted  due  to  multiprogramming. 


SJ  Required  Recompilatioos  List 

The  required  recompilations  list  reflects  any  inconsistencies  detected  in  the  library,  that  prevented  the  link  from 
taking  place. 

The  entries  in  the  list  contain  the  unit  name,  and  an  indication  of  the  unit  being  a  declaration  unit,  a  body  unit, 
or  a  subunit.  The  list  is  in  a  recommended  recompilation  order,  consistent  with  the  dependencies  among  the 
units. 

If  the  number  of  recompilations  is  smaU,  they  can  usually  be  performed  by  hand  using  this  list.  Otherwise,  the 
Ada  Recompiler  (see  Chapter  6)  may  be  used  to  accomplish  the  recompilation  in  a  fully  automatic  way. 

Examples  of  required  recompilation  lists  can  be  found  in  Chapter  10. 


5J.4.  Return  Status 

After  an  Ada  link  the  VAX/VMS  EXTL  symbols  Ssutns  and  Sseverity  will  reflect  whether  the  link  was  success¬ 
ful.  The  possible  values  of  Sseverity  and  the  low-order  bits  of  Sstatus  arc  any  of  the  values  defined  by  DCL. 


5.3.5.  linking  Summary 

The  linking  summary  contains  the  following  information: 

•  parameters  and  active  qualifiers; 

•  the  VAX/VMS  file  names  of  the  sublibrahes  constituting  the  current  program  library, 

•  the  number  of  each  type  of  diagnostic  messages; 

•  a  termination  message,  telling  whether  a  linking  has  terminated  successfully  or  unsuccessfully. 


5-12 


The  Ada  Linker 


5.4.  Commands  for  Defining  the  Ihrget  Environment 

rhere  are  a  aumber  of  diffeiwni  larger  enviiODjLcata  that  Ada  progiaiiis  can  run  In,  due  io  iliScicat  U3p!cc:e3- 
tadoos  of  the  MIL-STD-175QA  architecture. 

Each  of  these  environments  may  require  some  changes  to  either  the  standard  linker  control  statements,  or  the 
runtime  ezecutive  modules,  that  are  used  in  an  Ada  link.  These  changes  may  be  effected  by  various  Ada  link 
qualifiers  and  their  logical  name  defaults,  as  described  in  Secdon  S.1.1.  However,  convenience  commands,  of 
the  form  nse-  (for  example,  oseact  for  the  InterACT  17SQA  instiuedon  Set  Architecture  Simulator),  exist  to 
define  the  appropriate  Ada  5nk  logical  names.  These  commands  are  invoked  before  an  Ada  link,  and  remain  in 
effect  for  subsequent  Ada  links  until  changed  by  another  such  command. 

These  commands  are  described  in  full  detail  in  the  Ada  17SQA  Rimdme  Executive  Programmer’s  Guide. 
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^^.Pi^ENDiy  ^  OF  THE  Ada  STANDARD 


The  only  allowed  implementation  dependencies  correspond  to 
implementation-dependent  pragmas,  to  certain  machine-dependent 
conventions  as  mentioned  in  Chapter  13  of  the  Ada  Standard,  and  to 
certain  allowed  restrictions  on  representation  clauses.  The 
implementation-dependent:  characteristics  of  this  Ada  implementation, 
as  described  in  this  Appendix,  are  provided  by  the  customer.  Unless 
specifically  noted  otherwise,  references  in  this  Appendix  are  to 
compiler  documentation  and  not  to  this  report. 
Implementation-specific  portions  of  the  package  STANDARD,  which  are 
not  a  part  of  Appendix  F,  are: 


package  STANDARD  is 

type  INTEGER  is  range  -32_768  ..  32_767; 

type  LONG_INTEGER  is  range  -2_147_483_648 . . 2_147_483_647 ; 

type  FLOAT  is  digits  6 

range  -1.0*2.0**127. .0.999999*2.0**127; 

type  LONG_FLOAT  is  digits  9 

range  -1.0*2.0**127  ..  0.99999999*2.0**127; 

type  DURATION  is  delta  l.OE-04 

range  -214_748 . 3648 . . 214_748 . 3647 ; 


end  STANDARD; 
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This  appendix  describes  all  implementation-dependent  characteristics  of  the  Ada  language  as  implemented  by 
the  InterACT  Ada  175QA  Compiler,  including  those  required  in  the  Appendix  F  frame  of  Ada  RM. 


F.l.  cdeflned  Types  in  Package  STANDARD 

This  seoiou  describes  the  implementation-dependent  predefined  types  declared  in  the  predefined  package 
STANDARD  [Ada  RM  Annex  C],  and  the  relevant  attributes  of  these  types. 


F.1.1.  Integer  Types 

Two  predefmed  integer  types  are  implemented,  INTEGER  and  LONG_INTEGER.  They  have  the  following 
attributes: 


INTEGER’FIRST 

INTEGER’LAST 

INTEGER’SIZE 


-32  768 
32  767 
16" 


LONG  INTEGER’FmST 

LONG'INTEGER’LAST 

L0NG"INTEGER’SIZE 


-2_147  483  648 
2  147  483  ~(A1 
32  “  ■ 


F.U.  Floatiiig  Point  Types 

Two  predefined  floating  point  types  are  implemented,  FLOAT  and  LONG_FLOAT.  They  have  the  following 
attributes: 


FLOATDIGITS 

FLOATEPSILON 

FLOATFIRST 

FLOATLARGE 

FLOATLAST 


6 

9J3674316406250E-07 
-1.0  *  2.0**127 
1.93428038904620E+25 
0.999999  •  2.0*  *127 


FLOATMACHINE  emax 


127 
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FLOATMACHINE  EMIN 
FLOATMACHINE'MANnSSA 
FLOATMACHiNE'O  VcRFLO  WS 

floatmachine'radix 

floatmachine'rounds 

floatmantissa' 

FLOATSAFE  EMAX 

floatsafe’large 

floatsafe'small 

FLOATSIZE  ■ 


-128 

23 

TRUE 

2 

FALSE 

21 

127 

FLOATLAST 
OJ  •  2.0**(-127) 
32 


LONG  FLOATDIGITS 

long’floatepsilon 

long'floatfirst 

long'floatlarge 

long'floaplast 


9 

93D22574615479E-10 
-1.0  •  2.0**127 
10**124*(1.0-10**(-31)) 
.99999^*  2.0*’127 


LONG  FLOATMACHINE  EMAX 
LONG'FLOATMACHINE  EMIN 
LONG'FLOATMACHINE'MANnSSA 

long'floatmachine'overflows 

long'floatmachine'radix 

long'floatmachine'rounds 

long’floatmantissa' 

LONG’FLOATSAFE  EMAX 

long'floatsafe'i  arge 
long'floapsafe'small 

L0NG"FL0ATSI2E  ' 


127 
- 128 
39 

TRL'E 

2 

FALSE 

31 

127 

LONG  FLOATLAST 
03  •  2”(-127) 

48 


F.13.  Fixed  Point  lilies 

TWo  kinds  of  anonymous  predefmed  fixed  point  types  are  implemented, /ued  and  longjixed  (which  are  not 
defmed  in  package  STANDARD,  but  are  used  here  only  for  reference),  as  well  as  the  predefmed  t^ru;  DURA¬ 
TION. 

For  objects  of  fixed  types,  16  bits  are  used  for  the  representation  of  the  object.  For  objects  of  longjixed  types, 
32  bits  are  used  for  the  representation  of  the  object. 


For  faced  and  longjixed  there  is  a  virtual  predefined  type  for  each  possible  value  of  small  [Ada  RM  3.5.9] .  The 
possible  values  of  smaU  are  the  powers  of  two  that  are  representable  by  a  LONG_FLOAT  value,  unless  a  length 
clause  specifying  TSMALL  is  given,  in  Ntliich  case  the  spediled  value  is  used. 

The  lower  and  upper  bounds  of  these  types  are: 


lower  bound  of  fixed  types 
upper  bound  of  fixed  types 
lower  bound  of  longjixed  types 
upper  bound  of  longjixed  types 


-32768  •  small 
32767  •  small 
-2  147  483  648  •  small 
2  “l47  483  M7  *  small 


A  declared  fixed  point  type  is  represented  as  that  predefined  fixed  or  longjixed  type  which  has  the  largest  value 
of  small  not  greater  than  the  declared  delta,  and  which  has  the  smallest  range  that  includes  the  declared  range 
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constraint. 

Any  fixed  point  type  T  has  the  following  attributes: 


TMACHINE  OVERFLOWS  =  TRUE 
TMACHINE'ROUNDS  =  FALSE 


The  predefined  fixed  point  type  DURATION  has  the  following  attributes; 


DURATION’AFT 

DURATION’DELTA 

DURATION’FIRST 

DURATION’FORE 

DURATION’LARGE 

DURATION’LAST 

DURATION’MANTISSA 

DURATIObTSAFE  LARGE 

DURATI0N’SAFE"SMALL 

DURATION’SIZE  " 

DURATObTSMALL 


=  4 

=  l.OE-04 

=  -214  7483648 

=  7 

=  DURATION’LAST 
=  214  7483647 

=  31  ~ 

=  DURATION’LARGE 
=  DURATION’SMALL 
=  32 

=  l.OE-04 


F3.  Predefined  Language  Pragmas 


This  section  lists  all  language-defined  pragmas  and  any  restrictions  on  their  use  and  effect  as  compared  to  the 
definitions  given  in  Ada  RM. 


¥2.1.  Pragma  CONTROLLED 

This  pragma  has  no  effect,  as  no  automatic  storage  reclamation  is  performed  before  the  point  allowed  by  the 
pragma. 


¥22.  Pragma  ELABORATE 
As  in  Ada  RM. 


¥22.  Pragma  INLINE 

This  pragma  causes  inline  expansion  to  be  performed,  except  in  the  following  cases: 

1.  The  whole  body  of  the  subprogram  for  which  inline  expansion  is  wanted  has  not  been  seen.  This 
ensures  that  recursive  procedures  cannot  be  inline  expanded. 

2.  The  subprogram  call  appears  in  an  expression  on  which  conformance  checks  may  be  applied,  i.e.,  in  a 
subprogram  specification,  in  a  discriminant  part,  or  in  a  formal  part  of  an  entry  declaration  or  accept 
statement. 
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3.  The  subprogram  is  an  instantiation  of  t^'e  predefined  generic  subproEiams 
UNCHECKED_CON\'ERSION  or  UNCHECKED_DEALLOCATION.  Calls  lo  such  subproCTams 
are  expanded  inline  by  the  compiler  automatically. 

4.  The  subprogram  is  declared  in  a  generic  unit.  The  body  of  that  genep'*  unit  is  compiled  as  a  secon¬ 
dary  unit  in  the  same  compilation  as  a  unit  containing  a  call  to  (an  instance  of)  the  subprogram. 

5.  The  subprogram  is  declared  by  a  renaming  declaration. 

6.  The  subprogram  is  passed  as  a  generic  actual  parameter. 

A  warning  is  given  if  inline  expansion  is  not  achieved. 


FJA  Pngma  INTERFACE 

This  pragma  is  supported  for  the  language  names  defined  by  the  enumerated  type  INTERFACE_LANGUAGE 
in  package  SYSTEM.  Languages  other  than  BIF  support  Ada  calls  to  subprograms  whose  bodies  are  written  in 
that  language.  Language  BIF  (for  ’built-in  function')  supports  inline  insertion  of  assembly  language  macro  invo¬ 
cations;  the  macros  themselves  may  consist  of  executions  of  175QA  hardware  built-in  functions,  or  of  any 
sequence  of  175QA  instructions.  Thus,  pragma  INTERFACE  (BIF)  serves  as  an  alternative  to  machine  code 
insertions. 

Language  ASSEMBLY 

For  pragma  INTERFACE  (ASSEMBLY),  the  compiler  generates  a  call  to  the  name  of  the  subprogram.  The 
subprogram  name  must  not  exceed  31  characters  in  length.  Parameters  and  results,  if  any,  are  passed  in  the 
same  fashion  as  for  a  normal  Ada  call  (see  Appendix  P). 

Assembly  subprogram  bodies  are  not  elaborated  at  nmtime,  and  no  runtime  elaboration  check  is  made  when 
such  subprograms  are  called. 

Assembly  subprogram  bodies  may  in  turn  call  Ada  program  units,  but  must  obey  all  Ada  calling  and  environ¬ 
mental  conventions  in  doing  so.  Furthermore,  Ada  de{>endendes  (in  the  form  of  context  clauses)  on  the  called 
program  units  must  exist.  Toat  is,  merely  calling  Ada  program  units  from  an  assembly  subprogram  body  will 
not  make  those  program  units  visible  to  the  Ada  Linker. 

A  pragma  INTERFACE  (ASSEMBLY)  subprogram  may  be  used  as  a  main  program.  In  this  case,  the  pro¬ 
cedure  specification  for  the  main  program  must  contain  context  clauses  that  will  (transitively)  name  all  Ada 
program  units. 

If  an  Ada  subprogram  declared  with  pragma  INTERFACE  (ASSEMBLY)  is  a  library  unit,  the  assembled  sub¬ 
program  body  object  code  module  must  be  put  into  the  program  library  via  the  Ada  Library  Injection  Tool  (sec 
Chapter  7).  The  Ada  Linker  will  then  automatically  include  the  object  code  of  the  body  in  a  link,  as  it  would  the 
object  code  of  a  normal  Ada  body. 

If  the  Ada  subprogram  is  not  a  library  unit,  the  assembled  subprogram  body  object  code  module  cannot  be  put 
into  the  program  library.  In  this  case,  the  user  must  direct  the  Ada  Linker  to  the  directory  containing  the  object 
code  module  (via  the  /us«r_rts  qualifier,  see  Section  5.1),  so  that  the  1750A  Linker  can  find  it. 
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Language  BIF 

For  pragma  INTERFACE  (BIF),  the  compiler  generates  an  inline  macro  invocation  that  is  the  name  of  the 
subprogram.  The  subprogram  name  must  not  exceed  31  characters  in  length.  Subprogram  parameters  and 
results,  if  any,  are  passed  in  the  same  fashion  as  for  a  normal  Ada  call  (see  Appendix  P),  except  that  the  macro 
invocation  replaces  the  call.  However,  subprogram  parameters  may  be  passed  in  registers  if  pragma 
INTERFACE_PARAMETERS  is  used  (see  Section  FJ5.7).  Use  of  this  pragma,  as  well  as  pragma 
INTERFACE_SCRATCH  and,  if  desired,  pragma  INTERFACE_RESULT  (again,  see  Section  F3.7)  is  recom¬ 
mended  for  most  efficient  usage  of  pragma  INTERFACE  (BIF).  No  macro  arguments  are  passed  on  the  invo¬ 
cation. 

A  macro  file  must  exist  at  the  lime  of  the  compile  containing  a  macro  defmition  with  the  same  name  as  the  sub¬ 
program.  This  macro  file  must  be  available  by  one  of  the  means  documented  in  the  InterACT  175QA  Assembler 
and  Linker  User’s  Matmal. 

Languages  JOVIAL  and  FORTRAN 

These  languages  may  also  be  specified  for  pragma  INTERFACE,  but  are  equivalent  to  language  ASSEMBLY. 
The  compiler  generates  calls  to  such  subprograms  as  if  they  were  Ada  subprograms,  and  does  not  do  any  spe¬ 
cial  data  mapping  or  parameter  passing  peculiar  to  the  interACT  JOVIAL  or  FORTRAN  compilers. 


FJJ.  Pn^maLlST 
As  in  Ada  RM. 

¥2£.  Pragma  MEMORY  SIZE 

This  pragma  has  no  effect.  See  pragma  SYSTEM_NAME. 

¥2.1.  Pragma  OPTIMIZE 
This  pragma  has  no  effect. 


F2,8.  Pragma  PACK 

This  pragma  is  accepted  for  array  types  whose  component  type  is  an  integc',  :.c'jmeration,  or  fixed  point  type 
that  may  be  represented  in  16  bits  or  less.  (The  pragma  is  accepted  but  has  no  effea  for  other  array  types.) 

The  pragma  normally  has  the  effect  that  in  allocating  storage  for  an  object  of  the  array  type,  the  components  of 
the  olqect  are  each  packed  into  the  next  largest  2*  bits  needed  to  contain  a  value  of  the  component  type.  This 
calculation  is  done  using  the  minimal  size  for  the  component  type  (see  Section  F.6.1  for  the  definition  of  the 
minimal  size  of  a  type). 

However,  if  the  array's  component  type  is  declared  with  a  size  specification  length  clause,  then  the  components 
of  the  object  are  each  packed  into  exactly  the  number  of  bits  specified  by  the  length  clause.  This  means  that  if 
the  specified  size  is  not  a  power  of  two,  and  if  the  array  takes  up  more  than  a  word  of  memory,  then  some  com¬ 
ponents  will  be  allocated  across  word  boundaries.  This  achieves  the  maximum  storage  compaction  but  makes 
for  less  efficient  array  indexing  and  other  array  operations. 
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Some  examples: 

type  800C_ASR  is  srrsy  (1..32)  of  BOOLEAN;  ••  BOOLEAN  Minimal  size  is  1  bit 
pragma  PACK  (BOOL_ARR);  --  each  component  packed  into  1  bit 

type  TtNY_INT  is  range  -2..1;  --  minimal  size  is  2  bits 

type  TINy'arr  is  array  (1..32)  of  TINY_INT; 

pragam  PACK  (TINY_ARR);  --  each  component  packed  into  2  bits 

type  SMALL_INT  is  range  0..63;  --  minimal  size  is  6  bits,  not  a  power  of  two 

type  SMALL~ARR  is  array  (1..32}  of  SMALL_1NT; 

pragma  PACK  (SMALL_ARR);  --  thus,  each  component  packed  into  8  bits 

type  SMALL_INT_2  is  range  0..63;  --  minimal  size  is  6  bits,  but 

for  SMALL_1NT_2'SIZE  use  6;  this  time  length  Clause  is  used 

type  smALL_ARR_2  is  array  (1..32)  of  SHALL_INT_2; 

pragma  PACK  (siMLL_ARR_2};  --  thus,  each  caa^onent  packed  into  6  bits; 

soam  components  cross  word  botndaries 


Pragma  PACK  is  also  accepted  for  record  types  but  has  no  effect.  Record  representation  clauses  may  be  used  to 
'pack*  components  of  a  record  into  any  desired  number  of  bits;  see  Section  F.63. 


F3,9.  Pragma  PAGE 

As  mAda  RM. 


FJ.IO.  Pragma  rklORJTY 

As  in  Ada  RM.  See  the  Ada  17SQA  Runtime  Executive  Frogrammefs  Guide  for  how  a  default  priority  may  be 
set. 


FJ.11.  Pragma  SHARED 

This  pragma  has  no  effect,  in  terms  of  the  compiler  (and  a  warning  message  is  issued).  However,  based  on  the 
current  method  of  code  generation,  the  effect  of  pragma  SHARED  is  automatically  achieved  for  all  scalar  and 
access  objects. 


V2.n.  Pragma  STORAGE  UNIT 

This  pragma  has  no  effect.  See  pragma  SYSTEM  NAME. 


F3.13.  IVagma  SUPPRESS 

Only  the  'identifier*  argument,  which  identifies  the  type  of  check  to  be  omitted,  is  allowed.  The  '[ON  =  >] 
name'  argument,  which  isolates  the  check  omission  to  a  spedfic  object,  type,  or  subprogram,  is  not  supported. 

Pragma  SUPPRESS  with  all  checks  other  than  DFVISION^CHECK  and  OVERFLOW  CHECK  results  in  the 
corresponding  checking  code  not  being  generated.  The  implementation  of  arithmetic  operations  is  such  that,  in 
generic  pragma  SUPPRESS  with  DIVISION_CHECK  and  OVERFLOW_CHECK  has  no  effect.  In  this  case, 
runtime  executive  customizations  may  be  used  to  mask  the  overflow  interrupts  that  are  used  to  implement  these 
checks  (see  the  Ada  175QA  Runtime  Executive  Programmer’s  Guide  for  details).  However,  in  certain  cases 
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involving  multiplication  by  constants  or  numeric  type  conversions,  pragma  SUPPRESS  with 
DrVISION_CHECK  or  OVERFLOW_CHECK  results  in  code  being  generated  such  that  the  overflow  inter¬ 
rupt  cannot  occur. 


FJJ4.  Pragma  S\'STEM_NAME 

This  pragma  has  no  effect.  The  only  possible  SYSTEM_NAME  is  MIL  STD  1750A.  The  compilation  of 
pragma  MEMORY  SIZE,  pragma  STORAGE  UNIT,  or  thU  pragma  does  not  cause  an  implicit  recompilation 
of  package  SYSTEM. 


FJ.  UnplemenUtioa-dcpendent  Pragmas 


FJ.1.  Program  Library  Basis  Pragmas 

Certain  pragmas  defined  by  this  Compiler  System  apply  to  Ada  programs  as  a  whole,  rather  than  to  individual 
compilation  units  or  declarative  regions.  These  pragmas  are 

•  NO  DYNAMIC  OBJECTS  OR  VALUES  USED 

•  NO"DYNAMIc“MULTID^fENSIONAL_ARRAYS  USED 

•  SEf_MACHINE_OVERFLOWS_FALSE_FOR_AN6NYMOUS  FIXED 

These  pragmas  apply  on  a  program  library  wide  basis,  and  thus  apply  to  any  and  all  programs  compiled  and 
linked  from  a  given  program  library.  The  meanings  of  these  pragmas  is  described  in  the  subsections  below,  the 
way  in  which  these  pragmas  are  spedfied  is  described  in  this  subsection. 

These  pragmas  may  only  be  spedfied  within  the  implementation-denned  library  unit  LIBRARY  PRAGMAS, 
which  in  turn  may  only  be  compiled  into  a  root  (predefined)  sublibrary.  If  either  of  these  restrictions  are  not 
honored,  the  pragmas  have  no  effect. 

The  contents  of  this  library  unit  when  delivered  are 

p«Cka««  LIBRARY_PIUGMAS  is 

l«_0YMA»tIC_0eJECTS_0R_VALUES_USE0  :  constant  BOOLEAN  :»  FALSE; 

NO_OYNANIC_NULTIOI»IENSIONAL_A«RAYS_USED  ;  constant  "OOLEAN  ;■  FALSE; 
SET_NACHINE_OVE«FLOUS_FALSE_FOB_ANONYI«US_FIXED  ;  constant  BOOLEAN  :»  FALSE; 
and  LIBaA8Y_P1tAGMAS; 

In  order  to  spediy  any  or  all  of  the  pragmas,  the  source  for  this  package  is  modiHed  to  indude  the  pragmas 
after  the  constant  declarations  (the  source  file  is  defined  by  the  logical  name  actada  library_pragmas).  For 
example. 
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pKkafle  LIBSAIiY_PltACiMAS  is 

liO_0YI(AMIC_0iJECTS_0«_VALUES_USED  :  constant  800LEAM  :«  FALSE; 

NO_0YHAMIC_MULTIDIMENS10NAL_AARAYS_USED  :  constant  BOOLEAN  :«  FALSE; 
SET_NACHIME_OVERFLawS_FALSE_FOtt_ANONYNOUS_FlXED  :  constant  BOOLEAN  :>  FALSE; 
pragM  HO_OYNAMlC_a8JECTS_OK_VALUES_USEO; 
praoM  SET.NACH  I  NE_OVER  FLOUS_FALSE_FOil_ANON YMOUS_F  I XED  ; 
and  LIBRARY_PRAGMAS; 

This  modified  source  is  then  compiled  into  the  predefined  library. 

In  addition  to  the  efifects  described  in  the  subsections  below,  the  pragmas  have  the  effea  uf  changing  the  initiali¬ 
zation  value  to  TRUE  for  the  corresponding  constant  objects. 

If  unit  LIBRARY_PRAGMAS  is  modified  and  compiled  by  the  user,  it  must  be  compiled  before  any  other  user 
compilation  unit.  If  it  is  not,  the  program  will  be  erroneous. 

Note  that  while  these  pragmas  apply  to  an  entire  program  library,  it  is  possible  to  create  more  than  one  pro¬ 
gram  library  (via  the  Ada  FLU  command  create/root;  see  Chapter  3),  with  each  library  having  these  pragmas 
specified  or  not  according  to  user  desire. 

An  example  sequence  for  specifying  the  pragmas  for  the  delivered  program  library: 

$  act  dcf  sysSuser[libraries] 

$  copy  actada_Ubraryjpragnias  [llibrary_pregm8s_s.nda 
$  eve  library j>ragnias_s.ada 
<  add  desired  pragmas,  as  described  above  > 

$  adalTSO/libspredefinedJibrary  Ubrary_pragmaa_s 
$  adal750/piu  !  create  user  libraries  under  predefined 
create  appUcaaon.alb  predefined  library 
exit 

S  define  adal750_nbrary  application.alb 

An  example  sequence  for  specifying  the  pragmas  for  a  new  program  library,  leaving  the  delivered  program 
library  intact: 

$  set  def  sysSuser[Ubraries] 

$  adal750/plu  !  create  new  predefined  library 

create/root  pragmas^rooudb 

exit 

S  copy  actada_llbraryj>ragmas  []  library j)ragnias_ajida 

$  eve  library_pragniaa_ajida 

<add  desired  pragmas,  as  described  above> 

$  adal750/llbspragmas_rooLaib  library jpragmas^s 
S  adal750/plu  !  create  user  libraries  under  new  predefmed 
create  appiication.aIb  pragmas_rootaib 
exit 

$  define  adal750  library  applicatiorualb 
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¥32.  Pragma  NO_DYNAMIC_OBJECTS_OR_VALUES_USED 

This  pragma  works  on  a  program  library  basis.  See  the  subsection  at  the  beginning  of  this  section  for  bow  such 
pragmas  are  used. 

Use  of  this  pragma  informs  the  compiler  all  aeated  objects  and  all  computed  values  have  statically  known 
The  language  usages  that  do  not  meet  this  assertion  are 

•  TIMAGE  for  integer  types 

•  arrays  objects  or  values  of  (sub)types  with  non-static  index  constraints,  or  *  ith  component  subtypes 
with  non-statk  index  constraints 

•  array  aggregates  of  an  unconstrained  type 

•  catenations  (even  with  statically  sized  operands) 

•  collections  with  non-static  sizes 

Programs  that  violate  the  assertion  of  this  pragma  are  erroneous. 

The  effect  of  this  pragma  is  to  use  a  different,  and  more  efficient,  set  of  compiler  protocols  for  nmtime  stack 
organization  and  register  usage.  These  variant  protocols  are  described  in  Appendix  P. 


¥33.  Pragma  NO_DYNAMIC_MULTIDIMENSIONAL_ARRAyS_USED 

This  pragma  works  on  a  program  library  basis.  See  the  subsection  at  the  beginning  of  this  section  for  how  such 
pragmas  are  used. 

Use  of  this  pragma  informs  the  ipiler  that  all  declarations  of  multidimensional  array  types  or  objects  have 
static  index  constraints  [Ada  RM  4.9  (11)],  and  that  the  component  subtypes  of  such  arrays,  if  arrays  them¬ 
selves,  also  have  static  index  constraints.  Ihat  is,  all  multidimensional  arrays  have  statically  known  size.  Pro¬ 
grams  that  violate  the  assertion  of  this  pragma  are  erroneous. 

The  effect  of  this  pragma  is  to  use  a  special  technique,  known  as  bias  veaon,  in  the  generated  code  for  the  cal¬ 
culation  of  array  indexed  component  offsets  for  muld-dimensional  arrays.  This  technique  mvolves  building  a 
data  structure  that  contains  some  precomputed  offsets,  and  then  indexing  into  that  structure.  The  major  advan¬ 
tage  of  this  technique  is  that  few  or  no  multiplication  operations  need  be  generated.  The  major  drawback  is 
that  additional  literal  area  space  is  required,  although  this  can  be  minimized  if  the  first  dimension  of  the  array  is 
the  shortest 

The  bias  vector  data  structures  are  allocated  as  part  of  elaboration  of  the  constrained  array  subtype  declaration 
(or  object  declaration  that  implicitly  declares  su^  a  subtype). 

Bias  vectors  are  not  used  if  the  array  index  base  type  is  LONG_INTEGER  or  if  pragma  PACK  applies  to  the 
array. 
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FJ.4.  Pragmas  ESTABLISH  OPTIMIZED  REFERENCE  and  ASSUME  OPTIMIZED  REFERENCE 

These  pragmas  are  used  to  direct  the  compiler  to  generate  code  that  more  efficiently  references  objeas  in  a 
package.  This  efficiency  is  achieved  by  using  a  base  register  to  address  the  package  objects. 

Pragma  ESTABLlSH_OPTIMlZ£D_R£FER£NCE  instructs  the  compiler  to  load  a  base  register  with  the 
heginning  address  of  the  objects  in  the  designated  package,  and  to  access  such  objects  using  the  base  register. 
The  inagma  has  the  form 

pragma  ESTABLISH_OPTIMTZF.D_RJEFERENCE  {package  jiamt)-. 

The  pragma  may  appear  anywhere  within  a  program  unit;  the  load  and  subsequent  usage  of  the  base  register 
will  begin  at  the  point  of  the  pragma  appearance.  The  pragma  applies  only  to  the  program  unit  it  appears  in;  it 
does  not  apply  to  program  units  nested  within  that  unit. 

Pragma  ASSUM£_0PTIM1ZED_R£FER£NCE  instructs  the  compiler  to  assume  that  the  designated 
package’s  beginning  address  has  been  loaded  into  a  base  register,  and  to  access  such  objects  using  the  base 
register.  The  pragma  has  the  form 

pragma  ASSUME_OPTIMT7.ED_REFERENCE  (package jaiat)\ 

The  pragma  should  appear  at  the  beginning  of  the  declarative  part  of  a  program  unit.  The  pragma  applies  only 
to  the  program  unit  it  appears  in;  it  does  not  apply  to  program  units  nested  within  that  unit.  It  is  not  necessary 
to  use  this  pragma  after  an  instance  of  pragma  ESTABLJSH_OPTIMTZED_R£FERENCE;  rather,  it  must  be 
used  in  program  units  that  are  called  from  the  unit  that  contains  the  pragma 
ESTABLISH_OPTIMI21ED_REFER£NCE.  If  there  are  intervening  (in  terms  of  calls)  units  between  the  unit 
containing  pragma  ESTABLISH_OPi  IMTZF.D_REFERENCE  and  the  unit  desiring  to  use  pragma 
ASSUME  OPTIMIZED  REFERENCE,  then  those  intervening  units  must  also  use  pragma 

assume^optimized'reference. 

The  pragmas  apply  only  to  packages  that  are  library  units.  Only  the  objects  in  the  specification  part  of  the 
package,  and  within  base  register  range  of  the  package  beginning,  are  accessed  by  base  register. 

Only  one  base  register  is  used  by  these  pragmas,  that  being  register  12.  Thus,  the  pragmas  can  be  in  effect  for 
only  one  package  at  any  given  time  during  execution. 

An  example  of  the  use  of  these  pragmas: 

package  GLOML.VARS  it 
and  CLOML.VARS; 

with  CU.OML_V/UIS;  uta  GL08AL_VMS; 
procadura  P  it 

pragat  ESTAgLlSN_aPTINIZEO_REFERENC£  tGLOSAL.VARS); 
procadura  INNER  it 

pragaa  ASStME_aPTIMIZED_REFERENCE  (GLOBAL.VARS); 
bagin 

and  INNER; 
bagin 

INNER; 
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•fXl  P; 


F3S.  Pnsma  EXPORT 

This  pragma  is  used  to  define  an  external  name  for  Ada  objects,  so  that  they  may  be  accessed  &om  non-Ada 
routines.  The  pragma  has  the  form 

pragma  EXPORT  (objectjamc  [,extemn/_/iame_string_literal]); 

The  pragma  must  appear  immediately  after  the  associated  object  declaration.  If  the  second  argument  is  omit¬ 
ted,  the  object  name  is  used  as  the  external  name.  If  the  resulting  external  name  is  longer  than  31  characters,  it 
will  be  so  truncated. 

The  associated  object  must  be  declared  in  a  library  package  (or  package  nested  within  a  library  package),  and 
must  not  be  a  statically- valued  scalar  constant  (as  such  constants  are  not  allocated  in  memory). 

Identical  external  names  should  not  be  put  out  by  multiple  uses  of  the  pragma  (names  can  always  be  made 
unique  by  use  of  the  second  argiunent). 

As  an  example  of  the  use  of  this  pragma,  the  objects  in  the  following  Ada  library  package 

packaa*  GLOBAL  U 

ABLE  :  FLOAT; 
pragma  EXPORT  (ABLE); 

■AKER  :  STRING(1..8}; 

pragma  EXPORT  (BAKER,  "global .bakar"); 

and  GLOBAL; 

may  be  accessed  in  the  following  assembly  language  routine 


NODULE 

LOM_LEVEL 

CSECT 

(X»E 

EXTREF 

ABLE 

LOL 

ABLE.RO 

;  got 

111 

s 

e 

5 

m 

> 

EXTREF 

GLOBAL. BAKER 

LO 

BGLOBAL. BAKER, R2 

;  mt 

addrtsa  of  BAKER 

END 

F3JS.  Pragma  IMPORT 

This  pragma  is  used  to  associate  an  Ada  object  with  an  object  defined  and  all(x:ated  externally  to  the  Ada  pro¬ 
gram. 

pragma  IMPORT  {object jumt  [,eztema/_rtame_string_litcral]); 

The  pragma  must  appear  immediately  after  the  associated  object  declaration.  If  the  second  argument  is 
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omitted,  the  object  name  is  used  as  the  external  name.  If  the  resulting  external  name  is  longer  than  31  charac¬ 
ters,  it  will  be  so  truncated. 

The  associated  oiqect  must  be  declared  in  a  library  package  (or  package  nested  within  a  library  package).  The 
associated  object  may  not  have  an  explicit  or  implicit  initialization. 

As  an  example  of  the  use  of  this  pragma,  the  objects  in  the  following  Ada  library  package 


package  GLOML  it 

ABLE  :  FLOAT; 
pragaa  IMPORT  (ABLE); 

BAKER  :  STR1NC(1..8); 

pragaa  IMPORT  (BAKER,  ■■glabal.baker'*); 

and  GLOBAL ; 


are  actually  defined  and  allocated  in  the  following  assembly  language  mcxlule 


MODULE  GLOBAL.VALUES 
CSECT  DATA 

EXTDEF  ABLE 
ABLE  RES  2 

EXTOEF  GLOBAL. BAKER 
GLOBAL. BAKER  OATAC  'abedafgh' 

EMO 


F3.7.  Pragmas  INTERFACE  PARAMETERS,  INTERFACE  RESULT  and  DMTERFACE  SCRATCH 

These  pragmas  are  used  in  conjunction  with  pragma  INTERFACE  (BIF)  to  name  the  specific  1750A  machine 
registers  to  be  used  during  BIF  prexessing. 

The  type  PRAGMA_INTERFACE_PARAMETER_LXXiATIONS  in  package  SYSTEM  defmes  names  for  the 
17SQA  machine  registers  that  must  be  used  in  association  with  these  pragmas. 

Registers  10, 11,  and  IS  should  not  be  used  with  these  pragmas  as  they  serve  special  purposes  in  the  compiler 
(see  Appendix  P  for  details).  If  they  are  used,  it  is  the  user's  responsibility  to  save  and/or  restore  the  registers 
inside  the  BIF  macro. 

Sample  usage  of  these  pragmas: 

function  BIT.OPERATIOM  (X,  T  :  INTEGER)  rttum  INTEGER; 
pragM  INTERFACE  (BIF,  BIT  OPERATION); 

pragM  INTERFACE.PARAMETERS  (BIT_0PERATI0H,  X  ■>  R4,  Y  ■>  R5); 
pragaa  INTERFACE^RESULT  (BIT  OPERATION,  R9); 
pragaa  INTERFACE.SCXATCH  (BIT_0PERATI0N,  R6,  R3); 

Pragma  INTERFACE_PARAMETERS  spedfies  the  175QA  machine  registers  that  should  be  used  to  pass  the 
actual  parameters  of  the  subprogram.  If  this  pragma  is  not  spedfled,  the  subprogram  parameters  will  be  passed 
according  to  standard  compiler  protocol  (see  Appendix  P).  The  pragma  has  the  form 
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pragma  INTERFACE_PARAMETERS  (subprogram  jiame, 

parameter  name  =  >  pragma  interface jrarameterjocations  enumeration_literal 
[parameter  name  =  >  pragma  ^interface  _parom«c/-_/ocarionj_enumeration_literal]); 

Pragma  INTERFACE  RESULT  spedfies  the  17SQA  machine  register  to  be  used  for  a  function’s  return  result. 

If  this  pragma  is  not  provided,  registers  will  be  used  according  to  standard  compiler  protocol  (see  Appendix  P). 

The  pragma  has  the  form 

pragma  INTERFACE_RESULT  (subproffam_Dame,praffnaJnterface  jwamcfer_/ocanonj_enumeration_literal); 

This  pragma  will  only  be  accepted  for  a  fimction  and  cannot  be  used  if  the  result  type  is  an  array  or  record. 

Pragma  INTERFACE_SCRATCH  is  used  to  identify  the  17SQA  machine  registers  that  will  be  used  as  scratch 
registers  inside  the  macro.  If  the  pragma  is  provided,  the  compiler  will  only  save  those  registers  spedfied  in  the 
pragma  prior  to  BIF  execuuon.  If  this  pragma  is  not  provided,  the  compiler  will  save  all  necessary  registers 
prior  to  BEF  execution.  The  pragma  has  the  form 

pragma  INTERFACE  _SCRATCH  (subprogram jamc,  praffnajnterface jrarameterjocations  enumeration  literal 
[pragma  interface j><iromere/'_tocflrwww_enumeration_literal]); 


FJA  Pragma  INTERFACE  SPELLING 

This  pragma  is  used  to  defme  the  external  name  of  a  subprogram  written  in  another  language,  if  that  external 
name  is  different  from  the  subprogram  name  (if  the  names  are  the  same,  the  pragma  is  not  needed).  The 
pragma  has  the  form 

pragma  INTERFACE_SPELLING  (subprogram _name,  oi«ma/_name_string_literal); 

The  pragma  should  appear  after  the  pragma  INTERFACE  for  the  subprogram.  This  pragma  is  useful  in  cases 
where  the  desired  external  name  contains  characters  that  are  not  valid  in  Ada  identifiers.  For  example, 

procedure  CONNECT  BUS  (SIGNAL  :  INTEGER); 
pregne  INTERFACE  (ASSEMBLT,  C0NNECT_8US); 
preUMe  INTERFACE  SPELLING  (C0NNECT_iuS.  "SCONNECT.BUS”); 


FJJ.  Pragma  MEMORY  UNIT 

This  pragma  is  used  in  the  Compiler  System’s  support  for  memory  association.  This  is  where  Ada  objects 
(whether  variables  or  constants)  are  associated  at  compile  time  with  different  classes  of  memory.  Then  at  link 
time,  these  classes  of  memory  can  be  treated  differently.  For  instance,  objects  can  be  associated  with  fast 
memory  or  slow  memory,  with  local  or  global  memory  in  a  multiprocessor  environment;  with  different  areas  of 
memory  in  a  signal  processor/array  processor /SIMD  type  of  architecture;  and  so  on. 

The  classes  of  memory  are  implemented  through  the  InterACT  17SQA  Linker  CSECT  and  section  facilities  (see 
InterACr Linker  Reference  Manual  for  a  complete  description  of  these  facilities). 

The  types  MEMORYJECTION  NUMBER  and  USER_MEMORY_SECTIONS  in  package  SYSTEM  define 
the  CSECT  numbers  available  for  use  in  connection  with  this  pragma;  the  first  r  pe  defines  all  those  available 
in  the  175QA  Linker,  the  second  subtype  those  available  to  users  (not  reserved  by  the  compiler  or  runtime 
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executive). 

The  basic  scheme  of  the  memory  association  support  is  that  the  user  defmes  an  enumeration  type  naming  the 
different  flaw*  of  memory,  and  then  a  enumeration  representation  clause  assigning  each  of  those  classes  to  a 
CSECT  number.  Pragma  M£MORY_UNIT  is  then  defined  for  Ada  objects  (or  types,  applying  to  all  objects  of 
the  type),  specifying  the  memory  class  for  that  object.  The  compiler  allocates  the  object  in  a  CSECT  with  the 
corresponding  CSECT  number.  The  user  then  creates  17SQA  Linker  SECTION  control  statements  to  allocate 
the  memory  classes  as  desired. 

The  following  type  declarations  define  the  memory  classes.  The  user  must  code  them,  and  they  must  be  visible 
wherever  pragma  MEMORY_UNIT  appears. 

^  MEMORY  UNTT  ia 

(memory  unit  enumeration  literal  [/nemory  unit  enumeration  literal]); 

•Bbtype  RESERVED  MEMORY  UNITS  ia  MEMORY  UNirTnnge 
memory_unitjcnumcTitioaJiteTal.jnemoryjmitjta}xmtTa.tioaJitcTal 

for  MEMORY_UNIT  nse 

(memofy_umr_enumeration_literal  ^  >  csect_number 
(/n«moiy_untr_enumeration_literal  *  >  csect_numberj); 

The  first  declaration  defines  all  the  types  of  memory  that  (static  data  and  literal)  objects  and  types  can  be  asso¬ 
ciated  with,  and  the  CSECT  numbers  to  which  they  will  be  allocated.  The  second  declaration  specdfies  which  of 
these  kinds  of  memory  may  share  a  CSECT  with  existing  compiler  CSECTs  (e.g.  if 
memoryjinitjetumcrationJiteTsd  is  to  contain  both  the  stack/heap  and  some  static  data). 

Associations  of  particular  objects  and  types  to  memory  is  accomplished  by  the  following: 

pragma  MEMORY_UNTT  (memo#y_umt_enumeratioo_literal,  simple-name(,simple-name]); 

where  simple-name  is  a  type  or  objea.  Up  to  32  objects  and  32  data  types  may  be  specified  within  each 
occurrence  of  the  pragma. 

Any  base  type,  derived  type,  or  objects  of  them  may  be  associated.  Only  one  association  is  allowed  for  a  type  or 
an  object.  Once  a  type  is  associated,  all  objects  of  that  type  inherit  the  association.  When  associating  a  type,  it  is 
necessary  for  the  type  to  be  declared  in  same  package  as  the  pragma,  and  the  pragma  to  be  located  before  any 
objects  of  that  type  are  declared.  Any  objea  can  be  associated  providing  that  its  type  was  not  associated. 

This  pragma  may  be  used  m  any  compilation  unit  but  subprogram  variables  may  only  be  associated  with  a 
memory  that  shares  the  heap/suck  area. 

This  pragma  cannot  be  used  in  conjunction  with  address  clauses,  collections  or  pragmas 
ESTABUSH_OPTIMIZED_REFERENCE  and  ASSUME_OPTIMIZED_REFERENCE. 

FJJO.  Piragma  SET_MACHINE_OVERrLOWS_FALSE_FOR_ANONYMOUS_FIXED 

This  pragma  works  on  a  program  Ubrary  basis.  See  the  subsection  at  the  beginning  of  this  section  for  how  such 
pragmas  arc  used. 

The  effea  of  this  pragma  is  that  any  fixed  point  type  T  of  anonymous  predefmed  fixed  type  (i.e.,  represented  in 
16  bits)  has  the  attribute 
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FMACHINEOVERFLOWS  =  FALSE 
such  that  NUMERIC_ERROR  is  not  raised  in  overflow  situations  [Ada  RM  4.5. 7(7)]. 

The  result  of  operations  in  overflow  situations  is  either  the  lower  or  upper  bound  of  the  'virtual’  predefmed 
type  for  T  {{Ada  RM  3.5.9  (iO)],  this  document  Section  F.l),  depending  on  the  direction  of  overflow.  These 
bounds  are  •32_768  *  PSMALL  and  32_767  *  TSMALL  respectively.  These  bounds  will  equal  TFIRST  and 
TLAST  if  the  range  constraint  for  T  is  so  declared. 

Note  that  this  implementation  of  fixed  point  types  relies  on  the  17SQA  fixed  point  overflow  interrupt  being 
enabled  and  not  masked;  any  user  exit  or  customization  routines  in  the  Ada  runtime  executive  must  not  do 
differently. 


FJJl.  Pragma  SUBPROGRAM  SPELLING 

This  pragma  is  used  to  define  the  external  name  of  an  Ada  subprogram.  Normally  such  names  are  compiler¬ 
generated,  based  on  the  program  library  unit  number.  The  pragma  has  the  form 

pragma  SLBFROCiRAM  SPELLING  (subpro^amjaame  [^emaijuune  string_literal]); 

The  pragma  is  allowed  wherever  a  pragma  INTERFACE  would  be  allowed  for  the  subprogram.  If  the  second 
argument  is  omitted,  the  subprogram  name  is  used  as  the  external  name.  If  the  resulting  external  name  is 
longer  than  31  charaaers,  it  will  be  so  truncated. 

This  pragma  is  useful  in  cases  where  the  subprogram  is  to  be  referenced  from  another  language. 


F.4.  ImpicmcnUtioa-dependent  Attributes 
None  are  defmed. 


FJ.  Package  SYSTEM 

The  specification  of  package  SYSTEM  is: 
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package  SYSTEM  i« 


type  ADDRESS  it  new  INTEGER; 

AODRESS.NULL  :  constant  ADDRESS  0; 

type  NAME  it  (MIL_STDJ750A); 

STSTEM.NAME  :  conatant  NAME  :«  MIL_ST0J750A; 


STORAGE.UNIT  :  constant  16; 

NEMORT_SI2£  :  conatant  64  •  1024; 


MIN_INT 
MAX  j  NT 
NAX'OIGITS 
NAX^NANTISSA 
FINE  DELTA 
TICK 


:  conatant  ;■  -2_147_4a3_647-1; 

:  constant  :«  2_T47_4a3_647; 

:  constant  :■  9; 

:  constant  :>  31; 

:  conatant  :>  1.0  /  2.0  **  NAX.MANTISSA; 
:  constant  :>  0.000_100; 


tubtypa  PRIORITY  it  INTEGER  range  0..255; 


type  INTERFACE_LANGUAG£  it  (ASSEMBLY,  RIF,  JOVIAL.  FORTRAN); 
type  MEM0RY_SECTI0N_NUM8ER  it  range  0..31; 

tubtyp*  US£i_NEMORY_SECTiaNS  it  MEMORY_SECTION_NUM8ER  range  16.. 31; 

type  PRAGMA_INTERFACE_PARAMETER_LOCATIONS  is 

(RO,  R1,  R27  R3,  R4,  R5.  R6,  87, 

R8,  R9.  RIO,  811,  812,  813,  R14,  R15>; 


end  SYSTEM; 


7jS.  Type  Representatioa  Clauses 

The  three  kinds  of  type  representation  clauses  -  length  clauses,  enumeration  representation  clauses,  and 
record  representation  clauses  -  are  all  allowed  and  supported  by  the  compiler.  This  section  describes  any  res¬ 
trictions  placed  upon  use  of  these  clauses. 

Change  of  representation  [Ada  RM  13.6\  is  allowed  and  supported  by  the  compiler.  Any  of  these  clauses  may 
be  spedTied  for  derived  types,  to  the  extent  permitted  by  Ada  RM. 


F.6.1.  Length  Clauses 

The  compiler  accepts  all  four  kinds  of  length  clauses. 

She  spedflcadon:  TSIZE 

The  size  specification  for  a  type  T  is  accepted  m  the  following  cases. 

If  T  is  a  discrete  type  then  the  spedfied  size  must  be  greater  than  or  equal  to  the  minimal  she  of  the  type, 
is  dm  number  of  bits  needed  to  represent  a  value  of  the  type,  and  must  be  less  than  or  equal  to  the  size  of  the 
underlying  predefined  integer  type. 

The  calculation  of  the  minimal  size  for  a  type  is  done  not  only  in  the  context  of  length  clauses,  but  also  in  the 
context  of  pragma  PACK,  record  representation  clauses,  the  TSIZE  attribute,  and  unchecked  conversion.  The 
definition  presented  here  applies  to  all  these  contexts. 
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The  minimal  size  for  a  type  is  the  minimum  number  of  bits  required  to  represent  all  possible  values  of  the  tv-pe. 
When  the  minimal  si2e  is  calculated  for  discrete  types,  the  range  is  extended  to  include  zero  if  necessary.  That 
is,  both  signed  and  unsigned  representations  are  taken  into  account,  but  not  biased  representations.  Also,  for 
unsigned  representations,  the  component  subtype  must  belong  to  the  predefmed  integer  base  type  normally 
associated  with  that  many  bits. 

Some  examples: 

type  9ULL_1NT  1«  range 

for  SMALL_TnT'SIZE  use  2;  --  OK,  signed  representation,  needs  nininun  2  bits 

type  U_SMAtL_INT  is  range  0..3; 

for  U_9(ALL_TNT'StZE  uae  2;  --  OK,  inaigned  representation,  needs  einiMi  2  bits 

type  l_SMALL_IXT  is  range  7.,10; 

for  ■_iMLL_TNT'StZE  use  2;  --  illegal,  would  be  biased  representation 

for  ■_SNALL_INT'SIZE  uae  4;  --  OK,  the  extended  0..10  range  needs  Minioun  4  bits 

type  U_BIC_IMT  is  range  0..65_535; 

for  U_ilG_TNT'SIZE  use  16;  --  illegal,  range  outside  of  16*bit  INTEGER  predefined  type 

for  u'bIGJNT'SIZE  use  17;  ••  OK,  range  within  (17-bit  nape  to)  32-bit  L0NG_1NTEGER  predefined  type 

If  T  is  a  Hxed  point  type  then  the  spedfied  size  must  be  greater  than  or  equal  to  the  minimal  size  Oi  Lilw 
and  less  than  or  equal  to  the  size  of  the  underlying  predefined  fixed  point  type.  The  same  definition  of  minimal 
size  applies  as  for  discrete  types. 

If  T  is  a  floating  point  type,  an  access  type  or  a  task  type,  the  spedfied  size  must  be  equal  to  the  number  of  bits 
normally  used  to  represent  values  of  the  type  (floating  point  types  32  or  48,  access  types  16,  task  types  16). 

If  T  is  an  array  type  the  size  of  the  array  must  be  static  and  the  specified  size  must  be  equal  to  the  minimal 
number  of  bits  needed  to  represent  a  value  of  the  type.  This  calculation  takes  into  account  whether  or  not  the 
array  type  is  dedared  with  pragma  PACK. 

If  T  is  a  record  type  the  specified  size  must  be  greater  than  or  equal  to  the  minimal  number  of  bits  needed  to 
represent  a  value  of  the  type.  This  calculation  takes  into  account  whether  or  not  the  record  type  is  declared 
with  a  record  representation  clause. 

The  effect  of  a  size  specification  length  clause  for  a  type  depends  on  the  context  the  type  is  used  in. 

The  allocation  of  objects  of  a  type  is  unaffected  by  a  length  clause  for  the  type.  Objects  of  a  type  are  allocated 
to  one  or  more  storage  units  of  memory.  The  allocation  of  components  in  an  array  type  is  also  unaffected  by  a 
length  clause  for  the  component  type  (unless  the  array  type  is  declared  with  pragma  PACK);  components  are 
allocated  to  one  or  more  storage  units.  The  allocation  of  components  in  a  record  type  is  always  unaffected  by  a 
length  clause  for  any  component  types;  components  are  allocated  to  one  or  more  storage  units,  unless  a  record 
representation  clause  is  declared,  in  which  case  components  are  allocated  according  to  the  specified  component 
clauses. 

There  are  two  important  contexts  where  it  is  necessary  to  use  a  length  clause  to  achieve  a  certain  representa¬ 
tion.  One  is  with  pragma  PACK,  when  component  allocations  of  a  non-power-of-two  bit  size  are  de^ed  (see 
Section  F2.8).  The  other  is  with  unchecked  conversions,  where  a  length  clause  on  a  type  can  make  that  type’s 
size  equal  to  another  type’s,  and  thus  allowed  the  unchecked  conversion  to  take  place  (see  Section  F.9). 

Specification  of  coUectioa  size:  T’ST0RAGE_S1ZE 

This  value  controls  the  size  of  the  collection  (implemented  as  a  local  heap)  generated  for  the  given  access  type. 
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It  must  be  in  the  range  of  the  predefined  type  NATURAL.  Space  for  the  collection  is  deallocated  when  the 
scope  of  the  access  type  is  left. 

See  the  Ada  Runtime  Executive  Programmer's  Guide  for  full  details  on  how  the  storage  in  collections  is 
managed. 

Spedfleatioa  of  storage  for  a  task  activation:  'rSTORAGE_SlZE 

This  value  controls  the  size  of  the  stack  allocated  for  the  given  task.  It  must  be  in  the  range  of  the  predefined 
type  NATURAL. 

It  is  also  possible  to  speciiy,  at  link  time,  a  default  size  for  all  task  Starke,  that  is  used  if  no  length  clause  is 
present.  See  the  Ada  Runtime  Executive  Programmer's  Guide  for  full  details,  and  for  a  general  description  of 
how  task  stacks,  and  other  storage  associated  with  tasks,  are  allocated. 

Specification  of  a  small  for  a  fixed  point  type 

Any  real  value  (less  than  the  specified  delta  of  the  fixed  point  type)  may  be  used. 


F.6J.  Enumeration  Representation  Clauses 

Enumeration  representation  clauses  may  only  specify  representations  in  the  range  of  the  predefined  type 
INTEGER. 

When  enumeration  represenUtion  clauses  are  present,  the  representation  values  (and  not  the  logical  values)  are 
used  for  size  and  allocation  purposes.  Thus,  for  example, 

ryp*  ENUM  U  (ABLE,  BAKER,  CHARLIE}; 

for  ENUM  us«  (ABLE  »  1,  BAKER  ■>  4,  CHARLIE  «>  9); 

for  EHUM'SIZE  UNO  2;  ■*  fllesal,  1..9  rang«  needs  MiniiMjii  4  bits 

for  ENUM'SIZE  use  4;  ••  OK 

type  ARR  is  srrsy  (ENUM)  of  INTEGER;  --  will  occupy  9  words  of  storage,  not  3 


Enumeration  representation  clauses  often  lead  to  less  efficient  attribute  and  indexing  operations,  as  noted  in 
[Ada  RM  13.3  {6)]. 


V£2.  Record  RepreicnUtioa  Clauses 

Alignment  clauses  are  allowed,  but  the  only  permitted  value  is  one. 

In  terms  ot  allowable  component  clauses,  record  components  fall  into  three  classes: 

•  integer  and  enumeration  types  that  may  be  represented  in  16  bits  or  less; 

•  statically-bounded  arrays  or  records  composed  solely  of  the  above; 

•  all  others. 

Components  of  the  *16-bit  integer /enumeration’  class  may  be  given  a  component  clause  that  specifies  a  storage 
place  at  any  bit  offset,  and  for  any  number  of  bits,  as  long  as  the  storage  place  is  greater  than  or  equal  to  the 
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minimal  size  of  the  component  type  (see  Section  F.6.1)  and  does  not  cross  a  word  boundary. 

Components  of  the  *array/record  of  16-bit  integer/enumeration’  class  may  be  given  a  component  clause  that 
spedfies  a  storage  place  at  any  bit  offset,  if  the  size  of  the  array/record  is  less  than  a  word,  or  at  a  word  offset 
otherwise,  and  for  any  number  of  bits,  as  long  as  the  storage  place  is  large  enough  to  contain  the  component 
and  none  of  the  individual  integer/enumeration  elements  of  the  array /record  cross  a  word  boundary.  The  com¬ 
ponent  clause  cannot  specify  a  representation  different  from  that  of  the  component’s  type.  Thus,  an  array  com¬ 
ponent  that  is  given  a  packed  representation  by  a  component  clause  must  be  of  a  type  that  is  declared  with 
pragma  PACK;  similarly,  a  record  component  that  is  pven  a  non-standard  representation  by  a  component 
clause  must  be  of  a  type  that  is  declared  with  a  record  representation  clause. 

Components  of  the  'all  others*  class  may  only  be  given  component  clauses  that  specify  a  storage  place  at  a  word 
offset,  and  for  the  number  of  bits  normally  allocated  for  objects  of  the  underlying  base  type. 

Components  that  do  not  have  component  clauses  are  allocated  in  storage  places  beginning  at  the  next  word 
boundary  following  the  storage  place  of  the  last  component  in  the  record  that  has  a  component  clause. 

Records  with  component  clauses  cannot  exceed  2K  words  (32K  bits)  in  size. 


F.7.  Implementation-dependent  Names  for  Implementation-dependent  Components 
None  arc  defmed. 


F,8.  Address  Clauses 

In  general,  address  clauses  are  allowed  and  supported  for  objects,  for  subprogram  and  task  units,  and  for  inter¬ 
rupt  entries.  Address  clauses  are  not  allowed  for  package  units. 

Address  clauses  occurring  within  generic  units  are  always  allowed  at  that  point,  but  are  not  allowed  when  the 
units  are  instantiated  if  they  do  not  conform  to  the  implementation  restrictions  described  here.  In  addition,  the 
effect  of  such  address  clauses  may  depend  on  the  context  in  which  they  are  instantiated  (c.g.  library  package  or 
subprogram;  see  below). 


F,8.1.  Address  Clauses  for  Objects  or  Subprogram  Units 

Address  clauses  for  objects  or  subprogram  units  must  be  static  expressions  of  type  ADDRESS  in  package  SYS¬ 
TEM. 

Address  clauses  are  not  allowed  for  constant  scalar  objects  with  static  Initial  values,  as  such  objects  are  not  allo¬ 
cated  in  memory. 

Address  clauses  for  objects  declared  within  library  packages  cause  the  Compiler  System  to  reserve  space  for  the 
object  at  that  address,  since  the  object  exists  for  virtually  the  entire  length  of  Ada  program  execution.  Address 
cla’ises  for  oiqects  declared  within  subprograms  do  rot  cause  space  to  be  reserved  for  the  object,  since  the 
object  only  exists  during  the  subprogram’s  execution.  It  is  the  user's  responsibility  to  reserve  space  for  such 
objects  (17SQA  Linker  control  statements  may  be  used  if  desired). 

Type  ADDRESS  is  a  16-bit  signed  integer.  Thus,  addresses  in  the  memory  range  16#8000#..16#FFFF#  (Le., 
the  upper  half  of  17SQA  memory)  must  be  supplied  as  negative  numbers,  since  the  positive  (unsigned)  interpre¬ 
tations  of  those  addresses  are  greater  than  ADDRESS’LAST.  Furthermore,  addresses  in  this  range  must  be 
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declared  as  named  numbers,  with  the  named  number  (rather  than  a  negative  numeric  literal)  being  used  in  the 
address  clause.  The  hexadecimal  address  can  be  retained  in  the  named  number  declaration,  and  user  computa¬ 
tion  of  the  negative  equivalent  avoided,  by  use  of  the  technique  illustrated  in  the  following  example: 

X :  INTEGER; 

for  X  use  at  16#7FFF#;  -  legal 
Y :  INTEGER; 

for  Y  use  at  16#FFFF#;  -  illegal 

ADDR  FFFF ;  constant :  *  16#FFFF#  -  65536; 

Y :  INTEGER; 

for  Y  use  at  ADDR_FFFF;  -  legal,  equivalent  to  unsigned  16#FFFF# 


F,&2.  Address  Clauses  for  Interrupt  Entries 

Address  clauses  for  interrupt  entries  do  not  use  type  SYSTEMADDRESS;  rather,  the  address  clause  must  be  a 
static  integer  expression  in  the  range  0..15,  naming  the  corresponding  175QA  interrupt. 

The  following  restrictions  apply  to  interrupt  entries.  An  interrupt  entry  must  not  have  formal  parameters. 
Direct  calls  to  an  interrupt  entry  are  not  allowed.  An  accept  statement  for  an  interrupt  entry  must  not  be  part  of 
a  selective  wait,  Le,  must  not  be  part  of  a  select  statement.  If  any  exception  can  be  raised  from  within  the  accept 
statement  for  an  interrupt  entry,  the  accept  statement  must  include  an  exception  handler. 

When  the  accept  statement  is  encountered,  the  task  is  suspended.  If  the  specified  interrupt  occurs,  execution  o^ 
the  accept  statement  begins.  When  control  reaches  end  of  the  accept  statement,  the  special  interrupt  entry  pro¬ 
cessing  ends,  and  the  task  continues  normal  execution.  Control  must  again  return  to  the  point  where  the  accept 
statement  is  encountered  in  order  for  the  task  to  be  suspended  again,  awaiting  the  interrupt. 

There  are  many  more  details  of  how  interrupt  entries  interact  with  the  175QA  machine  state  and  with  the  Run¬ 
time  Executive.  For  these  details,  see  the  Ada  175QA  Runtime  Executive  Proffwnmer's  Guide. 


¥3.  Unchecked  Conversion 

Unchecked  type  conversions  are  allowed  and  supported  by  the  compiler. 

Unchecked  conversion  is  only  allowed  between  types  that  have  the  same  size.  In  this  context,  the  size  of  a  type 
is  the  minimat  size  (see  Section  F.6.1),  unless  the  type  has  been  declared  with  a  size  spedfication  length 
in  which  case  the  size  so  specified  is  the  size  of  the  type. 

In  addition,  if  UNCHECKED_CONVERSION  is  instantiated  with  an  array  type,  that  array  type  must  be  stati¬ 
cally  constrained. 

In  general,  unchecked  conversion  operates  on  the  data  for  a  value,  and  not  on  type  descriptors  or  other 
compiler-generated  entities. 

For  values  of  scalar  types,  array  types,  and  record  types,  the  data  is  that  normally  expected  for  the  object.  Note 
that  objects  of  record  types  may  be  represented  in  two  ways  that  might  not  be  anticipated:  there  are  compiler- 
generated  extra  components  representing  array  type  descriptors  for  each  component  that  is  a  discriminant- 
dependent  array,  and  all  dynamically-size  array  components  (whether  discriminant-dependent  or  not)  are 
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represented  indirectly  in  the  record  object,  with  the  actual  array  data  in  the  system  heap. 

For  values  of  an  access  type,  the  data  is  the  address  of  the  designated  object;  thus,  unchecked  conversion  may 
be  done  in  either  direction  between  access  types  and  type  SYSTEMADDRESS  (which  is  derived  from  type 
INTEGER).  (The  only  exception  is  that  access  objects  of  unconstrained  access  types  which  designate  uncon¬ 
strained  array  types  cannot  reliably  be  used  in  unchecked  conversions.)  The  named  number 
SYSTEMADDRESS  NULL  supplies  the  type  ADDRESS  equivalent  of  the  access  type  literal  null. 

For  values  of  a  task  type,  the  data  is  the  address  of  the  task's  Task  Control  Block  (see  the  Ada  175QA  Runtime 
Executive  Proffommer’s  Guide). 

For  unchecked  amversions  involving  types  with  a  size  less  than  a  full  word  of  memory,  and  different  representa¬ 
tional  adjustment  within  the  word  (scalar  types  are  right-adjusted  within  a  word,  while  composite  types  are  left- 
adjusted  within  a  word),  the  compiler  will  correctly  re-adjust  the  data  as  part  of  the  conversion  operation. 

Some  examples  to  illustrate  all  of  this: 

type  BOOL.ARR  is  •rray(1..16)  of  BOOLEAN; 
pragoN  PACK  (BOOL_A*iR); 

ftXKtion  UC  is  hm  UNCHECKEO_CONVERSION  (B00L_ARR,  INTEGER);  ••  OK,  both  have  size  16 

type  BITS_8  is  srrsy(1..8}  of  BOOLEAN; 
pregM  PACK  (BITS.S); 

function  UC  is  new  UNCHECKEO.CONVERSION  (BITS_8,  INTEGER);  ••  illegal,  sizes  are  8  and  16 
type  SMALL.INT  is  range  -128.. 127; 

function  UC  is  new  UNCHECKED.CONVERSION  (BITS.S,  SMALLJHT);  --OK,  both  have  size  8 
type  BYTE  is  range  0..255; 

function  UC  is  new  UNCHECKEO.CONVERSION  (BITS_8,  BYTE);  —OK,  both  have  size  8 

type  BIG  BOOLEAN  is  new  BOOLEAN; 
for  BIG_ioOLEAN'SIZE  use  8; 

fwretion  UC  is  new  UNCHECKED .CONVERSION  (BITS_8,  8IG.B00LEAN);  --0K,  both  have  size  8 

SM  :  SMALL.INT;  --  actual  data  is  rightmost  byte  in  object's  word 
BI  :  BITS_8;  --  actual  data  is  leftmost  byte  in  object's  word 

SM  ;■  UC  (BI);  --  actual  data  is  moved  from  leftmost  to  rightmost  byte  as  part  of  conversion 


Calls  to  instantiations  of  UNCHECKED^CONVERSION  are  always  generated  as  inline  calU  by  the  compiler. 

The  instantiation  of  UNCHECKED^CONVERSION  as  a  library  unit  is  not  aUowed.  Instantiations  of 
UNCH£CK£D_CONVERSION  may  not  be  used  as  generic  actual  parameters. 
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F.10.  Other  Chapter  13  Areas 


FJ0.1.  Change  of  Representation 

Oiangft  of  representation  is  allowed  and  supported  by  the  compiler. 


FJOJ.  Repreaentation  Attributes 

All  representation  attributes  [Ada  RM  13.7.2,  13.7.3]  are  allowed  and  supported  by  the  compiler. 

For  certain  usages  of  the  X’ADDRESS  attribute,  the  resulting  address  is  ill-defmed.  These  usages  are;  the 
address  of  a  constant  scalar  oiqect  with  a  static  initial  value  (which  is  not  located  in  memory),  the  address  of  a 
loop  parameter  (which  is  not  located  in  memory),  and  the  address  of  an  inlined  subprogram  (which  is  not 
uniquely  located  in  memory).  In  all  such  cases  the  value  SYSTEMjADDR£SS_NULL  is  returned  by  the  attri¬ 
bute,  and  a  warning  message  is  issued  by  the  compiler. 

When  the  X’ADDRESS  attribute  is  used  for  a  package,  the  resulting  address  of  that  of  the  machine  code  asso¬ 
ciated  with  the  package  specification. 

The  X’SIZE  attribute,  when  applied  to  a  type,  returns  the  minimum  size  for  that  type.  See  Section  F.6.1  for  a 
full  definition  of  this  size.  However,  if  the  type  is  declared  with  a  size  spedfication  length  clause,  then  the  size 
so  specdfied  is  returned  by  the  attribute. 

Since  objects  may  be  allocated  in  more  space  than  the  minimum  required  for  a  type  (see  Section  F.6.1),  but  not 
less,  the  relationship  O’SIZE  >  «  TSIZE  is  always  true,  where  O  is  an  object  of  type  T. 


F.10  Machine  Code  Insertions 

Machine  code  insertions  are  not  allowed  by  the  compiler.  Note  that  pragma  INTERFACE  (6IF)  may  be  used 
as  an  alternative  to  machine  code  insertions. 


F.10.4.  Unchecked  Deallocation 

Unchecked  storage  deallocation  is  allowed  and  supported  by  the  compiler. 

Calls  to  instantiations  of  UNCHECKED_DEALLC)CATION  are  always  generated  as  inline  calls  by  the  com¬ 
piler. 

The  instantiation  of  UNCHECKED_DEALLX3CATION  as  a  library  unit  is  not  allowed.  Instantiations  of 
UNCHECK£D_DEALLOCATION  may  not  be  used  as  generic  actual  parameters. 
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F.ll.  Input-Output 

The  predefined  library  generic  packages  and  packages  SEQUENTIAL_IO,  DIRECT  10,  and  TEXT  lO  are 
supplied  However,  file  input-output  is  not  supported  except  for  the  standard  input  and  output  files.  Any 
anempt  to  create  or  open  a  file  will  result  in  US£_ERROR  being  raised 

TEXT_IO  operations  to  the  standard  input  and  output  files  are  implemented  as  input  from  or  output  to  some 
visible  device  for  a  given  implementation  of  MIL-STD-17SQA.  Depending  on  the  implementation,  this  may  be  a 
console,  a  workstation  disk  drive,  simulator  files,  etc  See  the  Ada  17SQA  Runtime  Executive  Programmer’s 
Guide  for  more  details.  Note  that  by  default,  the  standard  input  file  is  empty. 

The  range  of  the  type  COUNT  defined  in  TEXT  lO  and  DIRECT_IO  is  0 ..  S  YSTEM.MAX  INT. 

The  predefined  library  package  LOW_LZVEL_IO  is  empty. 

In  addition  to  the  predefined  library  units,  a  package  STRING_OUTPUT  is  also  bcluded  in  the  predefmed 
library.  This  package  supplies  a  very  small  subset  of  T£XT_IO  operations  to  the  standard  output  file.  The 
specification  is: 

package  STRlNG_auTPUT  tc 

procedure  POT  (ITEH  :  in  STRING); 
procedure  POT_LINe  (ITEN  :  in  STRING); 
procedure  NEWSLINE; 
er^  STRING.OUTPUT; 

By  using  the  'IMAGE  attribute  function  for  integer  and  enumeration  types,  a  fair  amount  of  output  can  be  done 
using  this  package  instead  of  TEXT_IO.  The  advantage  of  this  is  ti^t  STRING  OUTPUT  is  smaller  than 
TEXT_IO  in  terms  of  object  code  size,  and  faster  in  terms  of  execution  speed. 

Use  of  TEXT_IO  in  multiprogramming  situations  (see  Chapter  S)  may  result  m  unexpected  exceptions  being 
raised,  due  to  the  shared  unit  semantics  of  multiprogramming.  In  such  cases  STRING_OUTPUT  may  be  used 
instead. 


FJ2.  ConpUer  System  Capacity  Limitations 

The  following  capacity  limitations  apply  to  Ada  programs  in  the  Compiler  System: 

•  the  space  available  for  the  constants  of  a  compilation  unit  is  32K  words; 

•  the  space  available  for  the  static  data  of  a  compilation  unit  is  32K  words; 

•  any  single  object  can  not  exceed  32K  words; 

•  the  space  available  for  the  objects  local  to  a  subprogram  or  block  statement  is  32K  words; 

•  the  names  of  all  identifiers,  including  compilation  units,  may  not  exceed  the  number  of  characters 
specified  by  the  INPUT  LINELENGTH  component  in  the  compiler  configuration  file  (see  Section 
4.1.4); 
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a  sublibrary  can  contain  at  most  4096  compilation  units  (library  units  or  subunits).  A  program  library 
can  contain  at  most  eight  levels  of  sublibraries,  but  there  is  no  limit  to  the  number  of  sublibraries  at 
each  level.  An  Ada  program  can  contain  at  most  32768  compilation  units. 


The  above  limitations  are  all  diagnosed  by  the  compiler.  Most  may  be  circumvented  straightforwardly  by  using 
separate  compilation  facilities. 


